Table of Contents. Project Server 2013 and 2016 Explore What's new for IT pros in Project Server 2013

Transcription

1 Table of Contents Project Server 2013 and 2016 Explore What's new for IT pros in Project Server 2016 What's new for IT pros in Project Server 2013 What's deprecated or removed in Project Server 2016 Plan Software requirements for Project Server 2016 Hardware and software requirements for Project Server 2013 BDM guidance for Project Server and Project Online TDM guidance for Project Server and Project Online Plan user access Plan for deployment Plan for performance and capacity in Project Server 2013 Plan EPM Solution architecture Plan for administrative and service accounts Project Server 2016 architecture Install and configure Deploy Project Server 2016 Deploy Project Server 2013 Upgrade to Project Server 2016 Upgrade to Project Server 2013 Operate and maintain OLAP database management Project Server 2013 backup and restore Queue and Database Administration (Project Server 2013) Periodic tasks for Project Server administrators Exchange Server calendar OOF integration with Project Server 2013 Use Project Server 2013 Administrator's Guide

2 Security Enterprise Custom Fields and Lookup Tables Database administration Operational Policies in Project Server 2013 Add SharePoint task list data to Project Server 2013 Technical reference Project Server 2016 cmdlets Global permissions in Project Server 2013 Category permissions in Project Server 2013 Default categories in Project Server 2013 Default group permissions in Project Server 2013 SharePoint Permissions Mode default permissions for Project Server 2013 SharePoint groups Project Server knowledge articles Scenarios and solutions Transitioning projects from SharePoint to Project Server 2013 Using workflow for demand management in Project Server Portfolio analysis overview

3 Learn how to plan, deploy, manage users in Project Server. Plan for Project Server Install and Configure Project Server Plan user access in Project Server Featured articles Software requirements Project server architecture Deploy Project Web App Project Server 2016 cmdlets

4 Explore Project Server 12/13/ min to read Edit Online Summary: Use these articles to learn more about new features available in Project Server. Applies to: Project Server 2016, Project Server 2013 Evaluation articles about Project Server The following articles about Project Server 2016 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT What's new for IT pros in Project Server 2016 What's new for IT pros in Project Server 2013 What's deprecated or removed in Project Server 2016

5 What's new for IT pros in Project Server /13/ min to read Edit Online Summary: Learn about Project Server Find information on the latest features and capabilities and get an overview of its new and updated functionality. Applies to: Project Server 2016 This article provides a brief overview of new and significantly updated functionality in Project Server 2016, with a particular emphasis on the areas of interest to IT professionals. These include the following: Resource Engagements One installation - Project Server and SharePoint Server Base installation languages and language packs Hardware and software requirements Upgrading to Project Server 2016 A single database for multiple instances Custom field limits Project Web App changes Resource Engagements The new Resource Engagements capabilities in Project Server 2016 helps project managers and resource managers to align with each other on the specific amount of work and time periods for specific resources associated with a project. Resource Engagements are an evolution of the old Resource Plan feature in Project Web App and all of your existing Resource Plan data can be converted to Resource Engagements as an optional part of the upgrade process. Resource Engagements provides you with the following: Project Managers can use the new Resource Plan view in Project Professional 2016 to create requests for resources. Resource Managers can view all requests for resource through the new Resource Requests page and can use the capacity planning heat map to provide them with availability information on their resources. IT-Pros will need to know how to migrate their Project Server 2013 Resource Plans to use as Resource Engagements in Project Server This will be done as part of the upgrade process by running a SharePoint PowerShell cmdlet. Note For more information about migrating your Project Server 2013 Resource Plans to Resource Engagements, see Upgrading to Project Server 2016.

6 Note For more information about Resource Engagements, see Overview: Resource Engagements. One installation - Project Server and SharePoint Server One of the biggest changes in Project Server 2016 is the installation process. The new Project Server 2016 runs as a service application in SharePoint Server 2016 Enterprise. The SharePoint Server 2016 Enterprise MSI file will contain the installation files for Project Server 2016 as well, so a separate installation is no longer required as it was in previous versions of Project Server. Activating Project Server 2016 will require an activation key. Important The Enterprise version of SharePoint Server 2016 is required to enable Project Server Project Server 2016 cannot be enabled on SharePoint Server 2016 with a Standard license. For more detailed information about deploying Project Server 2016, see Deploy Project Server Note Project Server 2016 runs as a service application in SharePoint Server 2016, so Project Server administrators should read about its new features and functionality. For information about new features and functionality in SharePoint Server 2016, see New and improved features in SharePoint Server Base installation languages and language packs Since Project Server 2013 and SharePoint Server 2013 were installed separately, it was sometimes necessary to consider languages for the base installation and languages packs to provide multi-language support for your users. For example, you might install both Project Server 2013 (English -US) and SharePoint Server 2013 (English - US), and then add the Project Server 2013 (French) language pack in a scenario in which you want to provide either a English-US and French Project Web App interface for your users. Now that both the new Project Server 2016 and the new SharePoint Server 2016 are installed through a single installation, the base language is automatically matched for both. For example, when you install SharePoint Server 2016 (English - US), the base installation language for both Project Server 2016 and SharePoint Server 2016 will be English - US. There is a special case in which the base installation language for SharePoint Server 2016 and Project Server 2016 do not match: SharePoint Server 2016 Project Server 2016 Thai English Language packs SharePoint Server 2016 language packs will also match languages for both Project Server 2016 and SharePoint Server Individual language packs for Project Server 2016 are not available. Since Project Server 2016 does not provide a matching language for all available SharePoint Server 2016 language packs, an alternate language is provided. The following table lists SharePoint Server 2016 language packs in which an alternate Project Server 2016 language is provided.

7 SharePoint Server 2016 language pack Azeri (Latin) Basque Bosnian Bulgarian Catalan Croatian Dari Estonian Gaelic Irish Galician Hindi Indonesian Kazakh Latvian Lithuanian Macedonian Malay Serbian (Latin) Thai Vietnamese Welsh Project Server 2016 language English Spanish English English Spanish English English English English Spanish English English Russian English English English English English English English English Note For more information about Project Online supported languages, see Supported languages for Project Online. Hardware and software requirements

8 Since Project Server 2016 is now a service application in SharePoint Server 2016, the hardware, software, and browser requirements for Project Server 2016 will be the ones specified for SharePoint Server Some notable requirements for this version are: Supported Server Operating Systems : Supported Database Server : Supported browser s: Windows Server 2016 Standard or Datacenter Windows Server 2012 R2 Microsoft SQL Server 2016 RTM The 64-bit edition of Microsoft SQL Server 2014 with Service Pack 1(SP1) SQL Analysis Services must also be installed if you are using the Cube Building Service in Project Server Microsoft Edge Microsoft Internet Explorer 11 Microsoft Internet Explorer 10 Google Chrome (latest released version) Mozilla Firefox (latest released version plus immediate previous version) Apple Safari (latest released version) Project client compatibility You can connect to Project Server 2016 with not only Project Professional 2016 and the Project Online Desktop Client, but also with Project Professional Version Compatible with Project Server 2016 Project Professional 2016 Project Online Desktop Client Project Professional 2013 Project Server 2013 Project Professional 2016 Project Online Desktop Client Project Professional 2013 Project Server 2010 Project Server 2010 Project Professional 2007 with Service Pack 2 Project Professional 2007 with Service Pack 2 can only connect if Backwards Compatibility is enabled on Project Server 2010 Note If you are using Resource Engagements in Project Server 2016, the new Resource Plan view for Resource Engagements is not available in Project Professional You must use Project Professional 2016 or the Project Online Desktop Client to use the Resource Plan view. Note For more information about the hardware and software requirements for SharePoint Server 2016, see Hardware and software requirements for SharePoint Server 2016 Beta 2. > For more information about supported browsers for SharePoint Server 2016, see Plan browser support in SharePoint Server 2016 Beta 2.

9 Upgrading to Project Server 2016 When planning to upgrade to Project Server 2016 take note of the following: Upgrade only through Project Server If you are upgrading from earlier versions of Project Server, you must upgrade your databases to Project Server 2013 first in order to upgrade to Project Server There is no direct upgrade path from Project Server 2010 to Project Server Project Web App site collection upgrade - The SharePoint 2013 content database that contains your PWA site collection needs to be upgraded as well during the upgrade process. No in-place upgrade - You must first create a Project Server 2016, and then attach and upgrade your Project Server 2013 databases to the new farm. In-place upgrade is not supported. Upgrade through SharePoint PowerShell - Similar to the Project Server 2013 upgrade experience, upgrading to Project Server 2016 will be through the use of SharePoint PowerShell cmdlets. Migrate your Project Server 2013 Resource Plans - You can migrate your Project Server 2013 Resource Plans to use as Resource Engagements in Project Server 2016 as an optional part of the upgrade process. Resource Plans are not supported in Project Server For more detailed information about the upgrade process, see Upgrading to Project Server A single database for multiple instances In Project Server 2013, a separate Project database is created for each Project Web App instance. In Project Server 2016, a single database (the SharePoint content database) will be used for all instances of PWA. Even though all data is saved to the single database, data from each individual instance is still isolated from other instances. Having your Project data contained within a single database makes for easier database operations, such as backup and restore, migration, etc.. Note Direct access to the reporting schema is supported only if there is a single instance of Project Web App that uses the database. Custom field limits To help provide the best performance in Project Server 2016 reporting, there are limits to how many single-value custom fields, or each type, that get stored in the reporting schema: Project custom fields Timesheet custom fields Task and Resource custom fields, combined 450 text fields 450 text fields 450 text fields 450 lookup tables 450 lookup tables 450 lookup tables 450 of all other custom field types (cost, date, duration, number, flag) 450 of all other custom field types (cost, date, duration, number, flag) 450 of all other custom field types (cost, date, duration, number, flag) Project Web App changes

10 Administrators should know of a couple of big changes in Project Web App that affects your users: New Timeline options In Project Server 2016, note that there are several changes to the way timelines are used in Project Web App. These include: WHAT'S NEW Multiple timelines - You have the ability to have multiple timelines. You can add an additional timeline through the Project Center or Schedule page. Adjust the timeline date range - You are now able to adjust the start and end date of a timeline. HOW DO I DO THIS? Project Center -Add projects and tasks to the Project Center timeline Schedule page -Add tasks to a project timeline Change the appearance of a timeline in Project Web App Easier way to create a project In Project Server 2016, you can easily create a new project through the Get Started with Project Web App window that displays on the Project Web App home page. Selecting Create or Import project will start the Create a new project wizard that will help guide your user through the required steps. Note For more information, see Create a project in Project Web App. See also New and improved features in SharePoint Server 2016

11 What's new for IT pros in Project Server /13/ min to read Edit Online Summary: Learn about new features and capabilities in Project Server Applies to: Project Server 2013 This article provides a brief overview of new and significantly updated functionality in Project Server 2013, with a particular emphasis on the areas of interest to IT pros. These areas include the following: Project Online in Office 365 Project Server 2013 architecture changes Multi-tenancy support Database consolidation Project site availability in SharePoint Server 2013 Project mobile availability Demand Management improvements OData service for better reporting Improvements in Exchange integration with Project Server SharePoint task-list projects and enterprise projects My Tasks: All tasks in one location Administrative Settings user interface changes SharePoint Permission Mode Project site permissions Active Directory synchronization improvements Better logging and monitoring Project Server 2013 upgrade changes Note Project Server 2013 is built on SharePoint Server 2013, so Project Server users should read about its new features and functionality. For information about new features and functionality in SharePoint Server 2013, see Explore SharePoint Project Online in Office 365 The release of Project Server 2013 is paired with the release of a new service in Office 365 for enterprises, Project Online. With Project Online, all operational maintenance is handled through an online service that is hosted in Microsoft datacenters, which allows you to focus on core project management tasks. Project Online in Office 365 delivers full Project Portfolio Management (PPM) capabilities (Demand Management, Portfolio Management, Resource Management, Reporting, and so on). Portfolio managers, project managers, and team members can access Project Online from anywhere with an Internet connection.

12 The Project Online offering provides the following benefits: IT Pro administration All operational maintenance is handled through the Project Online service. You no longer have to commit IT resources to tasks such as updates, disaster recovery, and maintenance. Also, preventive maintenance scripts are run on your databases to prevent problems before they happen. Easy startup There are no up-front infrastructure costs and users are on a simple per user licensing basis. Security Office 365 employs robust disaster recovery capability, globally-redundant back-ups, and extensive privacy features. Filters help protect users against spam and viruses. Guaranteed uptimes Microsoft offers guaranteed, financially-backed up times and phone support 24 hours a day, seven days a week. Note For more information about how to use Project Online, see Getting started with Project Online. Project Server 2013 architecture changes Project Server 2013 is a multi-tiered system that extends the architecture introduced in Office Project Server The front-end tier includes Project Professional 2013, Project Web App, and third-party applications. Client applications communicate with the middle tier through the Project Server Interface (PSI) or through the client-side object model (CSOM) endpoints, which in turn communicate with the PSI and the business object layer. Database access is integrated in the business objects. The Project Server Eventing System can access both local and remote event handlers. The Project Calculation Service duplicates the Project Professional scheduling engine. Client applications do not (or should not) directly access the Project Web App database; Project Server hides business objects from clients. At a high-level, some key architecture changes for Project Server 2013 include the following: Database consolidation: Driven by an effort to reduce total cost of ownership (TCO), Project Server 2013 data is consolidated into a single Project Web App database. The benefits of a single database are described in the Database consolidation section of this document. Azure Workflow: Declarative workflows (workflows that are defined in SharePoint Designer 2013) are offloaded to Azure Workflow for processing. Azure Workflow can run on a separate server in the SharePoint farm, on Azure in the cloud, or on a single Project Server computer for testing or demonstrations. Coded workflows that are developed with Visual Studio 11 Beta are processed in the workflow runtime within SharePoint Server, as in Project Server OData services for reporting: Project Online users and users of Project Server 2013 on-premises can both access their reports through the OData service. Open Data (OData) is an industry standard web protocol used to access data from external systems. The OData service internally runs SQL queries on the Reporting tables and views. This is especially helpful for Project Online users, because the Project Web App database cannot be directly accessed in Azure. Project Server 2013 users will still be able to directly access the Reporting table and views through SQL Server in order to create reports. For more information, seeintroducing OData: Data Access for the web, the cloud, mobile devices and more in the MSDN Library. Project Server Queuing system: In Project Server 2013, timesheet jobs do not use the queue system (no Timesheets queue). All sites served by the same application service share the same queue service. Several key changes have greatly improved queue performances. When a job is posted to the queue table, the system will be notified that a job is available, instead of periodically having to poll for queue jobs. Azure cloud services for Project Online: For Project Online users in Office 365, data is stored in the Azure cloud services operating system.

13 Note For more information about Project Server 2013 architecture, see Project Server 2013 architecture overview. Multi-tenancy support Unlike Project Server 2010, Project Server 2013 supports the ability to accommodate multiple tenants when used in conjunction with the SharePoint Server 2013 multi-tenancy feature. This gives you the ability to have multiple customers, business units, or departments on the same SharePoint Server and Project Server farm and infrastructure. For example, in a hosted environment you can have separate Project Server 2013 instances for two separate companies. Or in a company, you can have your legal department using a Project Server 2013 instance that is completely independent of other instances used by other departments. Each Project Server 2013 tenant shares use of the Project Application Service, but it runs independent of, and isolated from, the other. Database consolidation In Project Server 2013, the Project Service provides project management functionality not only to Project Web App (PWA) but also throughout the SharePoint Server 2013 farm in which it resides. One major change is the use of a single Project Web App database for Project Server In Project Server 2010, each Project Server 2010 instance was supported by a set of four Project Server databases (Draft, Publish, Reporting, and Archive). For Project Server 2013, all four Project Server 2013 databases are consolidated into a single database, the Project Web App database (default name: ProjectWebApp). The Reporting tables retain their previous names, and the Draft, Published, and Archived table names have the prefixes draft., pub., and ver. Direct access is not supported for the Draft, Published, and Archive tables and views. Reports should only use the Reporting tables and views. These changes are driven by the need to reduce total cost of ownership (TCO) for using Project Server 2013, especially when you are implementing an environment in which you may have multiple PWA instances in your environment. A reduction in the number of databases required to use Project Server 2013 reduces the costs associated to maintain the data (update, backup, disaster recovery, and so on). Project site availability in SharePoint Server 2013 The project site feature provides basic project management functionality in all SharePoint Server 2013 versions. The project site feature provides SharePoint Server 2013 users a team collaboration site in order to manage projects. Project sites in SharePoint Server 2013 enable people in an organization to effectively collaborate on lightweight projects. Project managers can quickly get a sense of what is going on in a project, and team members can quickly see how their work fits into the overall context. Project sites also enable teams to access and share relevant data, documents, and communication. A project site provides the following: Project Summary Web Part Visual timeline of the project's tasks Complete task schedule for a project Library for storing relevant project documents Notebook for quickly capturing and organizing information about the project Shared calendar for team events

14 Ability to connect to the Project 2013 client application When SharePoint Server 2013 is connected to Exchange Server, a project site can also include a team mailbox for unified communication about the project as it progresses. When a project site is part of a site collection that is associated with Project Server 2013, it can also be used to capture issues, risks, and deliverables, and it can be switched to full control (versus managed mode) for more robust Project Server 2013 functionality. Although project sites offer the SharePoint Server user lightweight project management capabilities, eventually your environment might evolve to a point where you require additional features. For example, you might have numerous project sites and require a collective view of the information. When you need added project management functionality, a structured method allows you to easily migrate your project site data to Project Server For more detailed information about how to use project sites in SharePoint Server 2013, see Getting started with a project site. Project mobile availability A new addition in Project Server 2013 is support for mobile access to your project data. A web-based mobile site is now included, which enables team members and project managers to view project status at a glance on a mobile device. By using the touch-enabled mobile site, you can access and edit relevant project documents and do lightweight editing of project plans from your Windows Phone 7.5 (using the Internet Explorer 9 browser), Apple iphone, or Android device. Mobile features are used primarily by two types of Project Server users: Team members Check tasks assignments in a Project site Interact with documents, tasks, and other information kept on a Project site View the roll-up of project status for Project Server and lightweight projects. Project managers Manage projects by using project sites View up-to-date status information from resources assigned to their projects wherever they are View project status information at a glance in a format that can be carried anywhere they need to go Make minor changes to the project plan on the fly Team members are also able to edit and submit task status through the Microsoft Exchange client on their telephones. Task synchronization between Exchange Server and SharePoint Server 2013 (the My Tasks page) is done through the Work Management Service. For information about mobile availability in SharePoint Server 2013, What's new in mobile devices (SharePoint 2013). Demand Management improvements Demand Management is the area of collecting "demand" for project ideas and proposals, and gathering information on those proposals. Proposals are then managed through portfolio management with triage and selection workflow, and then selected projects are executed and tracked by using Project Professional 2013 and Project Server 2013Project Server In Project Server 2010, workflows can be created and edited in Visual Studio. A key improvement in Project Server 2013 is the ability to use SharePoint Designer and the workflow

15 engine in SharePoint Server 2013 to create Project workflows for Demand Management. Demand Management in Project Server 2013 provides the following: A new proposal can be created and managed in SharePoint Server (say, with a SharePoint list) and seamlessly integrated with Project Server. 1. The project manager creates a SharePoint list for ideas and sets it up however she or he wants to. There are no requirements about how the list is set up for PPM Online to be able to work with it. 2. Once the PM decides that they want the list to be able to migrate items into Project Server, they can add the Manage Projects App to the list to expose that functionality. 3. (Optional) The user goes to the Project Server settings page in List Settings and sets up the mapping from the columns in the list to fields in Project Server. 4. The user promotes items in one of two ways: Manually, by selecting one or more items in a list view and clicking the Create Projects button on the Items tab of the ribbon. This opens a dialog box that allows the user to specify the column-field mapping (defaulted to the mappings set up in step 3) and the EPT to use, after which the projects are created for the selected items. Automatically, through a workflow action. The user sets up a regular SharePoint workflow on the list and uses the Project action ( Create Project from List Item) as part of that workflow. The action takes an EPT as a parameter and, when executed, uses the mapping set up in the earlier step to create a project from the current list item context. 5. In either case, the project is created in Project Server, and is created between the list item and the project (only new list items can be imported). In the case when users use the rich Demand Management platform with PDPs and EPTs (this was available in Project 2010), they can see a rich visualization of Project workflow status on the proposal (instead of a text table). OData service for better reporting A key change in Project Server 2013 reporting is the use of the OData service to access the Project Web App database. The use of OData was driven by the move to create a Project Online offering. In Office 365, the Project Web App database for Project Online cannot be accessed directly, so an OData service is available. For online customers, Reporting tables and views are exposed only by the OData interface. Project Online is designed to provide a separate database for each instance of Project Web App. That is, multiple instances of Project Web App each have their own Project Web App database. The OData service internally runs SQL queries on the Reporting tables and views in the Project Web App database associated with the specific instance of Project Web App. In Project Server 2013, users can also access the on-premises Reporting tables through the OData interface. Users of Project Server 2013 on-premises who have the correct permissions can directly access the Reporting tables and views through SQL Server to create reports just as they do in Project Server For example, the dbo.msp_project table and the dbo.msp_epmproject_userview view can be used for reports. Any tables or views that have a "draft.", "pub.", or "ver." prefix are for internal use by Project Server only, and are not for reporting use. For example, the draft.msp_tasks table and the pub.msp_projects_working_view view are not documented and are not for third-party use. The Reporting tables, views, and fields in the Project Web App database are documented in an HTML Help file in the Project 2013 SDK. The OData XML schema for the Reporting data will also be documented online on MSDN, in an update of the SDK. Queries of the Reporting tables and views that were created for Project Server 2010 will, in most cases, work with the Project Web App database in Project Server Users of Project Server 2013 on-

16 premises can access the Project Server OLAP cubes in SQL Server Analysis Services, as they currently do. In Project Online, OLAP cubes are not available. An additional change to reporting in Project Server 2013 is that Basic Power Pivot technology is integrated into the latest version of Excel. Project Server 2013 and Project Online both take advantage of this technology to design rich reports. Note For Project Server 2016, reports can be designed and viewed only in the Excel client. For information about how to configure reporting in SharePoint Server 2013, see Configure reporting for Project Web App (Project Server 2013). Improvements in Exchange integration with Project Server Exchange integration with Project Server was introduced in Project Server It provides the ability for team members or resources on a project to view, update, delete, and report status on their published tasks in Microsoft Outlook, Outlook Web App (OWA), or any other application that is capable of syncing tasks from Exchange Server. The Exchange integration feature in Project Server 2013 allows you integrate project task management by using SharePoint Server 2013 with Exchange Server This allows team members anywhere that have access to Exchange Server to interact with task management data in Microsoft Outlook or Outlook Web App and even using an Exchange-connected mobile device (by using either Windows Phone 7.5 or Apple IOS v5). Project Server 2013 with Exchange Server 2013 provides the following: Server to Server Open Authorization (OAuth) standard Connections between SharePoint Server 2013, Exchange Server 2013, and Lync Server Task synchronization with SharePoint and Outlook tasks. Note For more information about configuring task synchronization, see Configure Exchange task synchronization in SharePoint Server Exchange calendar out-of-office integration In Project Server 2013, we introduce the ability to synchronize a Project Server resource's calendar to their Microsoft Exchange calendar in order to retrieve and synchronize their out-of-office (administrative) time. This new functionality allows your resources to report their out-of-office time in a single location (Microsoft Exchange), and have it automatically synchronize to their Project Web App resource calendar. This feature is disabled by default, and is enabled in the Exchange Server Details section of the Additional Server Settings page of your Project Web App server settings. SharePoint task-list projects and enterprise projects The Project Application Service in Project Server 2013 can be associated with a SharePoint site collection in which the project sites are SharePoint task-list projects. When the project site is a SharePoint task-list project, SharePoint maintains the project site in a site collection. Project Professional can synchronize with and update the task lists. A project site can include an independent SharePoint task list or a task list that is synchronized with an.mpp file; the.mpp file can be stored locally or in a SharePoint library.

17 SharePoint task list projects can be converted so that Project Server maintains them as enterprise projects. In this case, Project Professional saves data directly to Project Server. The feature comparison table below compares the behavior of task lists, the Schedule Web Part, and other functionality for SharePoint task list projects and enterprise projects. The Schedule Web Part contains the grid on the Project Web App page where you can edit a project schedule. The following table provides a comparison of how various features work in visibility mode and full control: Comparison of SharePoint task list projects and enterprise projects FEATURE SHAREPOINT TASK LIST PROJECT ENTERPRISE PROJECT Task list in SharePoint Read-only Read/write Schedule Web Part Read-only Read/write Reporting Rich reporting through Project Server Rich reporting through Project Server Other Project Server functionality Blocked functionality: Server-side project edits, with Project Web App or custom client applications Statusing Tasks are not visible Full functionality is enabled Note For more information about SharePoint task lists, see Overview: View a SharePoint task list in Project Web App. My Tasks: All tasks in one location The My Tasks feature allows users to see an aggregation of their SharePoint, Project Server, and Microsoft Outlook/Exchange tasks in a single location the My Tasks page in a user's personal site. Instead of navigating to different lists, sites, and site collections to view and edit both SharePoint Server and Project Server tasks, users simply have to go to their My Tasks page to see a single collection of all the things they need to do. The My Tasks page allows you to update existing Project Server assignments, and the results are synchronized to Project Server For example, if you change the assignment status of an active Project Server 2013 task to Complete, the change is forwarded to Project Server The Work Management Shared Service in SharePoint Server 2013 provides the functionality for the My Tasks page. The Work Management Service is responsible for aggregating SharePoint tasks through Enterprise Search and Project Server task assignments through the Project application service. Tasks are not only collected to the My Tasks page, but they are also pushed to other applications in which they are configured to be viewed, such as Microsoft Outlook, or by mobile devices that synchronize to Exchange Server. You can synchronize tasks from SharePoint Server, your My Site, and Project Server into your Exchange Server mailbox and your Windows Phone tasks hub. Additionally, Exchange Server tasks can be synchronized into your My Tasks page. The Tasks section of the My Tasks page has various features to better organize your tasks. These include the following: Timeline: The timeline provides a visual representation of your recent and upcoming tasks relative to the current date. It can be configured through the Task settings page, but it provides a default view of all tasks one week into the past, and three weeks into the future.

18 Filters: Tasks can be filtered by a number of different settings, including by project, flagged and upcoming tasks, active tasks, new tasks, completed tasks, timesheet tasks, and task status reporting. Additionally, tasks can also be filtered by keyword search. Important tasks: You can use the "Important" flag to specify tasks that have special significance to you and make them viewable through the main view. Flags automatically expire over time to keep your list of important tasks current. Administrative Settings user interface changes In Project Server 2013, Administrative controls that are more IT-related were moved from the Project Web App Server Settings page to the SharePoint Central Administration site. The goal is to make the Server Settings page more suitable for PMO Administration and to move settings related to administering the farm to the Central Administration site. In Central Administration in SharePoint Server 2013, you can find the Manage Project Server Settings page in the General Application Settings section. This page contains the following configuration pages: Configuration pages for General Application Settings in SharePoint Server 2013 QUEUE AND DATABASE ADMINISTRATION OPERATIONAL POLICIES WORKFLOW AND PROJECT DETAILS PAGES Manage Queue Jobs Additional Server Settings Project Workflow Settings Daily Schedule Backup Administrative Backup Administrative Restore Server Side Event Handlers Project Site Provisioning Settings Bulk Update Project Sites OLAP Database Management The Project Queue settings have been relocated to the Manage Project Web Apps page in Central Administration. You can access this page by clicking the Project Service Application in the Service Application page in Central Administration. You can then view the queue settings by clicking the Manage Queue Settings for Project Web App link on the Manage Project Web App Sites page. SharePoint Permission Mode To both simplify Project Server permissions and more closely align the permissions configuration with SharePoint Server, the new default SharePoint Permission Mode has been created in Project Server It provides users an alternative to the "classic" Project Server permissions model (Project Permission Mode). A new installation of Project Server 2013 automatically starts you in SharePoint Permission Mode. If you require more detail in managing permissions, you can easily switch to the Project Permission Mode by using a Window PowerShell command. The following table illustrates the features available in each security mode. Comparison of security modes in Project Server 2013 FEATURE SharePoint PERMISSION MODE Project

19 FEATURE PERMISSION MODE Unified security management through SharePoint Server Permissions inheritance for PWA and Workspaces Direct authorization against Active Directory security groups Claims-based authorization Manage authorization by role-based groups Extensible and customizable User delegation Ability to secure work resources Impersonation Security filtering using the Resource Breakdown Structure Custom Security Categories Because SharePoint Permission Mode does not require synchronization between Project Server users and SharePoint sites, SharePoint Permission Mode uses fewer system resources and allows for greater scalability. Important Switching between SharePoint Permission Mode and Project Permission Mode deletes all security-related settings. If you switch from SharePoint Permission Mode to Project Permission Mode, you have to manually configure your security permissions structure in Project Server Switching from Project Permission Mode back to SharePoint Permission Mode deletes your security permissions information from Project Server One of the benefits of using SharePoint Permission Mode is that it attempts to separate IT and PMO roles. Site collection administrators are granted less control of PMO settings and pages, and they are granted more control over all aspects of the site collection. SharePoint Permission Mode creates SharePoint groups that directly correspond to the Project Server 2010 default Security Groups. SharePoint groups are created during the post-provisioning process and after transition to SharePoint Permission Mode. These Project Server 2013 SharePoint groups have the same global and category permissions that were typically assigned to them in Project Server In SharePoint Permission Mode, you cannot create additional custom groups, categories, Resource Breakdown Structure (RBS) nodes, or edit the default permissions assigned to any of these objects. The following table describes the Project Server 2013 SharePoint groups and what they are allowed to do within EPM: Project Server 2013 SharePoint groups SHAREPOINT GROUP EPM/PPM FUNCTION

20 SHAREPOINT GROUP Administrators Portfolio Viewers Project Managers Portfolio Managers Resource Managers Team Leads Team Members EPM/PPM FUNCTION Users have all global permissions and also category permissions through the My Organization category. This allows them complete access to everything in Project Server Users have permissions to view Project and Project Server data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks. Users have permissions to create and manage projects. This group is intended for project owners who assign tasks to resources. Users have assorted project-creation and team-building permissions. This group is intended for high-level managers of groups of projects. Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data. Users have limited permissions around task creation and status reports. This group is intended for persons in a lead capacity that do not have regular assignments on a project. Users have general permissions for using PWA, but limited project-level permissions. This group is intended to give everyone basic access to PWA. All new users are added to the Team Members group automatically. To switch from SharePoint Permission Mode to Project Permission mode, run the following Microsoft PowerShell cmdlet: Set-SPProjectPermissionMode -url <url> -mode ProjectServer To switch from Project Permission Mode to SharePoint Permission Mode, run the following Microsoft PowerShell cmdlet: Set-SPProjectPermissionMode -url<url > -mode SharePoint Project site permissions For project sites that are managed through SharePoint (in visibility mode), users of the site are assigned to one of three SharePoint groups with the following SharePoint Permission levels: GROUP NAME ProjectNameOwner ProjectNameMember SHAREPOINT PERMISSION LEVEL Full Control Contribute

21 GROUP NAME ProjectNameVisitor SHAREPOINT PERMISSION LEVEL Read If the project site is then switched from a SharePoint tasks list project to an enterprise project (where Project Server maintains the project site), the groups are then given Project Server global and category permissions, based on the group they are in: GROUP NAME ProjectNameOwner ProjectNameMember ProjectNameVisitor PROJECT SERVER PERMISSION LEVEL Full Permissions Basic Permissions Limited Permissions Project site users must be in at least one of the three SharePoint groups for them to be recognized when the project site is in full control. Users created at the root of the SharePoint site will not be recognized by Project Server, although they will have access to the site. Note For more information about SharePoint Permission Mode in Project Server 2013, see Plan groups, categories, and RBS in Project Server. Active Directory synchronization improvements In Project Server 2013, big improvements have been made to synchronization and timer job performance. Changes were made to improve the time required for synchronization of users in the Active Directory directory service with Project Server Enterprise Resource Pools (ERPs) and to Project Server security groups. These changes include the following: Introduced smarter scheduling: Synchronization jobs now run more during low usage times. Active Directory sync timer jobs can be scheduled through the Central Administration site. Reduced the number of RDB updates: Reporting synchronization jobs are more expensive to run than other job types. Reductions have been made in the number of jobs being run, and also in the types of jobs that are run. The result of these changes is marked improvements in the time required for synchronization jobs to run. The following table compares recent test results for Active Directory synchronization job times for a large group of users between Project Server 2010 SP1 and Project Server 2013: PROJECT SERVER 2010 SP1 SYNC JOB TIME PROJECT SERVER 2013 SYNC JOB TIME Initial Synchronization 20:01 7:43 Recurring Synchronization 14:07 00:24 Note For the above test scenario, there were users in 12+ nested groups.

22 Better logging and monitoring Project Server Log Level Manager is a feature in Project Server 2013 that allows administrators to throttle the logs for a specific entity (for example, a project, resource, job, and so on). When activated, all the logs about a specified entity are written to ULS even if the server is set to a higher level. The entity that you want to track is specified through its GUID through Log Level Manager. Whenever ULS notices a trace with that GUID, it adds it to logging. Although we do not recommend verbose logging for the entire farm, logging for the specific entity is verbose. The following entities can be tracked through Log Level Manager: Assignments Calendars Queue jobs Objects Projects TS periods Resources Tasks Templates timesheets Log Level Manager is configured through the following Microsoft PowerShell cmdlets: Add-SPProjectLogLevelManager: Run this cmdlet to add a new entity to watch. Just running this cmdlet would prompt the user to provide all the relevant parameters, including the PWA url, the type and GUID of the entity to watch, and the level of logging desired. Set-SPProjectLogLevelManager: Run this cmdlet to update an entry already added to the log watch list. With this cmdlet, for example, you can update the LogLevel. (By default it is Verbose.) Get-SPProjectLogLevelManager: Run this cmdlet to list all the entities added or entities belonging to a certain criteria. For example, you can list all the entities for a given entitytype or with an entityuid starting with a partial guid string. Clear-SPProjectLogLevelManager: Run this cmdlet to clear all the entities being watched. Remove-SPProjectLogLevelManager: Run this cmdlet to delete a specific entity represented by an Entityuid. Set-SPProjectLogLevelManagerRefresh: You must run this cmdlet after making LogLevelManager changes to update the cached list of entities to watch. For performance reasons, the process in charge of writing to the ULS logs does not query the database to look for changes in the list of entities to watch. It works off of a copy of this table in memory instead. This command is required to refresh that list in memory. Project Server 2013 upgrade changes The following are important things to note for upgrading to Project Server 2013: Full database-attach upgrade is the only available upgrade method when you upgrade to Project Server 2013Project Server In-place upgrade is not supported for upgrading to Project Server Backwards compatibility is not supported for Project Server If you want to connect to Project Server

23 2013 with a Project client, Project Professional 2013 is required. Project Professional 2010 does not connect to Project Server There is no direct upgrade path from Project Server 2007 to Project Server You must first upgrade to Project Server 2010 before upgrading your data to Project Server For information about how to upgrade from Project Server 2007 to Project Server 2010, see the Project Server 2010 Upgrade Overview on Microsoft TechNet. Because in-place upgrade is not supported, you must plan to have a Project Server 2013 environment to which you can migrate your Project Server 2010 data. For information about how to upgrade to Project Server 2013, see Upgrade to Project Server 2016.

24 12/13/ min to read Edit Online Applies to: Project Server 2016 What's deprecated or removed in Project Server 2016 Learn what has been deprecated or removed in Project Server This article describes features and functionality that have been removed in Project Server 2016 that had been previously available in Project Server Resource Plans My Tasks Project Server Interface (PSI) Project class removed Project Server Interface (PSI) members Project Server Interface (PSI) extensions Resource Plans In Project Server 2016, what was previously known as Resource Plans in Project Server 2013 has now evolved into Resource Engagements. Resource Engagements will allow project managers working in Project Professional 2016 or the Project Online Desktop Client to systematically place resource requests in order to build their project teams. Resource managers working in Project Server 2016 will then be able to modify, accept or reject those requests. Existing Resource Plans can be converted to Resource Engagements when you upgrade from Project Server 2013 to Project Server 2016 as an optional part of the upgrade process. The Resource Plan view will no longer be available in Project Professional Note For more information about Resource Engagements, see this blog post. For more information about migrating your Project Server 2013 Resource Plans to Resource Engagements as part of the Project Server 2016 upgrade process, see Upgrading to Project Server My Tasks The My Tasks and associated Exchange Task Sync features have been removed in SharePoint Server The Work Management Service Application that is required for both features has also been removed. Project Server Interface (PSI) Project class removed The Project class in the PSI is not supported in Project Server For all new development, use the Project Client Side Object Model (CSOM). WebSvcProject

25 Type Project ProjectContextDataSet ProjectDataSet ProjectImpactDataSet ProjectRelationsDataSet ProjectTeamDataSet SyncDataSet SyncErrorsDataSet Removed members All All All All All All All All Project Server Interface (PSI) members In Project Server 2016, the following PSI members have been removed: Note For more information about the Project Server Interface, see Project Server 2013 class library and web service reference Microsoft.Office.Project.Server.Library Type Activity CubeStatus.CbsProcessErrorId IPSContextInfo PSContextInfo PSErrorID PSEventID PSDBUtility Removed members PROPOSAL_REVIEW_APPROVAL_FEATURE_UID PROPOSAL_REVIEW_WORKFLOW_FEATURE_UID DsoTranslatorNotFound DsoNotInstalled Lcid PSContextInfo(Boolean, String, Guid, Guid, Guid, String) PSContextInfo(Boolean, String, Guid, Guid, Guid, Int32, String) Lcid SiteVersion LookupTableItemHasTrailingOrLeadingWhitespace Deprecated8 Deprecated9 IntArrayListToCommaDelimitedString

26 PSSecurityCategory PSSecurityGIobaIPermission PSSecurityObjectType Security ViewConstants.ViewType MyPersonaIProjects ChangeProjectState CreateNewProposalOrActivity DownloadPwaOutlookAddIn ManageStatusReports ViewDataAnalysis MaxBuildInObjectType Model PROPOSAL_APPROVERS_GROUP_UID VISION Microsoft.Office.Project.Server.WebServiceProxy Type Removed members LoginWindows Microsoft.Office.Project.Server.Workflow Type WorkflowStringIds Removed members SEND_ _PROJECT_COMPLETED_BODY STATUS_INITIALIZE_FAILED_INVALID_PROJECT WebSvcCubeAdmin Type CubeAdmin Removed members SetCubeBuiIdingSettings WebSvcEvents Type PSEventID Removed members Deprecated8 Deprecated9 WebSvcPortfolioAnalyses Type Removed members

27 AnalysisDataSet.AnalysisProjectsDataTable AnalysisDataSet.AnalysisProjectsRow AddAnalysisProjectsRow (AnalysisDataSet.AnalysisRow, Guid, String, Double, Double, DateTime, DateTime, DateTime, Int32, DateTime, DateTime, Byte) FNLT SNET WebSvcStatusing Type ProjectDataSet.TaskRow Removed members DurationType PROJ_OPT_CURRENCY_DIGITS PROJ_OPT_CURRENCY_POSITION PROJ_OPT_CURRENCY_SYMBOL WebSvcTimeSheet Type TimesheetListDataSet.TimesheetsRow Removed members TS_AUX_STATUS Project Server Interface (PSI) extensions In Project Server 2016, Project Server Interface (PSI) extension scenarios are not supported. These scenarios enabled integration with custom Windows Communication Foundation (WCF) services. Note For more information about PSI extensions, see the MSDN article Developing PSI Extensions. See also What's new for IT pros in Project Server 2016 What's deprecated or removed from SharePoint Server 2016 IT Preview New and improved features in SharePoint Server 2016 IT Preview

28 Plan for Project Server 12/13/ min to read Edit Online Summary: IT pros use planning and architecture content to develop conceptual, logical, and physical designs for configuring Project Server 2016 features, servers, and topologies. Applies to: Project Server 2016, Project Server 2013 TechNet articles about Project Server planning The following articles about Project Server planning are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. Software requirements for Project Server 2016 Planning Project Server and Project Online for business decision makers Planning Project Server and Project Online for technical decision makers Plan user access in Project Server IT Pro Planning for Project Server 2016 Project Server 2016 architecture

29 Software requirements for Project Server /14/ min to read Edit Online Summary: Learn about installation requirements for Project Server Applies to: Project Server 2016 Key Requirements In previous versions of Project Server, Project Server was installed separately after you installed SharePoint Server, as SharePoint Server was a requirement. Project Server 2016 installation is now a part of the SharePoint Server 2016 Enterprise installation process. The installation files for Project Server 2016 are included in the SharePoint Server 2016 Enterprise MSI file, and it is installed along with it. Important Project Server 2016 can only be enabled on the Enterprise version of SharePoint Server You will not be able to enable Project Server 2016 on SharePoint Server 2016 with a Standard license. Since Project Server 2016 is part of the SharePoint Server 2016 installation, requirements for Project Server 2016 (including supported browsers, operating systems, and database servers) will be the ones specified for SharePoint Server Some of the key software requirements for SharePoint Server 2016 are: Supported Server Operating Systems : Supported Database Server : Supported browsers : Windows Server 2016 Standard or Datacenter Windows Server 2012 R2 Microsoft SQL Server 2016 RTM The 64-bit edition of SQL Server 2014 with Service Pack 1 (SP1) SQL Analysis Services must also be installed if you are using the Cube Building Service in Project Server Microsoft Edge Microsoft Internet Explorer 11 Microsoft Internet Explorer 10 Google Chrome (latest released version) Mozilla Firefox (latest released version plus immediate previous version) Apple Safari (latest released version) Note For information about the hardware, software, and browser requirement for SharePoint Server 2016, see System requirements for SharePoint Server 2016 IT Preview. Client Compatibility You can connect to Project Server 2016 with not only Project Professional 2016 and the Project Online Desktop

30 Client, but also with Project Professional Also note that you will be able to use Project Professional 2016 and the Project Online Desktop Client, as well as Project Professional 2013, to connect to Project Server 2013 Version Compatible with Project Server 2016 Project Professional 2016 Project Online Desktop Client Project Professional 2013 Project Server 2013 Project Professional 2016 Project Online Desktop Client Project Professional 2013 Project Server 2010 Project Professional 2010 Project Professional 2007 with Service Pack 2 Project Professional 2007 with Service Pack 2 can only connect if Backwards Compatibility is enabled on Project Server 2010 Note If you are using Resource Engagements in Project Server 2016, the new Resource Plan view for Resource Engagements is not available in Project Professional You must use Project Professional 2016 to use the Resource Plan view. Cube Building Service requirements SQL Server 2014 Analysis Services must also be installed on your SQL Server 2014 database server for your SharePoint Server 2016 Enterprise deployment if you plan to use the Cube Building Service in Project Server Note SQL Server 2014 is the supported database server for SharePoint Server 2016 Enterprise. Portfolio Analysis Requirements For charts to render correctly in your browser when using Portfolio Analysis in Project Server 2016, the State Service needs to be running in your SharePoint farm. See also Deploy Project Server 2016 Hardware and software requirements for SharePoint Server 2016 Plan browser support in SharePoint Server 2016

31 Hardware and software requirements for Project Server /15/ min to read Edit Online Summary: Verify that your computer meets the hardware and software requirements that are listed in this article when you try to install Project Server Applies to: Project Server 2013 This article describes the following requirements: Hardware requirements: Small dataset hardware recommendations Medium dataset hardware recommendations Large dataset hardware recommendations Software requirements: Operating system SharePoint Server 2013 SQL Server Requirements for Project Server 2013 features Client requirements: Project Professional client compatibility Project Professional 2013installation requirements Project Professional 2013 through Office 365 ProPlus Project Web App requirements Project Server 2013 with the Microsoft Azure platform Hardware requirements for Project Server 2013 When you plan for the hardware that is required for a Project Server 2013 deployment, as a starting point, you should determine the usage requirements for your Project Server 2013 environment. These variables include the number of projects, tasks, users, average tasks per project, and so on. By using the How datasets affect performance and capacity in Project Server 2013 tables, you can compare the numbers from your environment to the data for small, medium, and large datasets defined in their corresponding table. By selecting the dataset that most resembles the usage requirements in your environment, you can use the recommended topology and associated hardware requirements for your topology as a starting point when you plan for hardware for your Project Server 2013 deployment. This section specifies the hardware requirements for a Project Server 2013 deployment based on the datasets defined in How datasets affect performance and capacity in Project Server 2013.

32 Note The minimum hardware requirements in this section are recommended in which only the required services to run Project Server 2013 are enabled. Be aware that enabling additional SharePoint Server 2013 features in the farm may require more resources. For more information about hardware and software requirements for SharePoint Server 2013, see Hardware and software requirements for SharePoint Small dataset hardware recommendations for Project Server 2013 The following are the recommended hardware requirements for a Project Server 2013 small dataset scenario. See How datasets affect performance and capacity in Project Server 2013 for more information about how the small dataset size is defined. Minimum requirements for hardware for small datasets in Project Server 2013 The minimum hardware topology for a small dataset scenario is a single-server deployment that contains the following three tiers: SQL Server Application server Front-end web server The minimum recommended hardware requirements for the servers in this dataset are as follows: Minimum hardware requirements for a small dataset in Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 24 GB for developer and evaluation use 80 GB for installation For production use, you need additional free disk space for day-to-day operations. Add two times as much free space as you have RAM for production environments. Recommended hardware for Project Server 2013 for a small dataset Project Server 2013 runs as a service application on SharePoint Server 2013, and usage by other service applications generates additional resource usage (processor, RAM, and hard disk). While the minimum recommended requirements are suitable for a small dataset with light usage, more substantial datasets and usage patterns may require additional hardware resources. For a single-server deployment with a small dataset, we advise 16 GB of RAM to assure a high level of perceived performance. We recommend that, if possible, you separate your SQL Server tier from the Application and front-end web tiers by placing your databases onto a dedicated computer that is running SQL Server. Server 1: Application and front-end web Server 2: SQL Server For a two-tiered deployment supporting a small dataset, we recommend the following hardware requirements: Front-end web and Application server hardware recommendations for Project Server 2013

33 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for production use 80 GB SQL Server hardware recommendations for Project Server 2013 for a small dataset COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core (If your dataset size is significantly larger than the medium dataset, we recommend 8 cores.) 16 GB 80 GB Medium dataset hardware recommendations for Project Server 2013 The following are the recommended hardware requirements for a Project Server 2013 medium dataset scenario. See How datasets affect performance and capacity in Project Server 2013 for more information about how the medium dataset size is defined. Minimum requirements for hardware for medium datasets for Project Server 2013 The minimum recommended hardware topology for a medium dataset scenario is a three-tier deployment that contains a dedicated server for each of the following: Server 1: Front-end web server Server 2: Application server Server 3: SQL Server For a three-tier deployment supporting a medium dataset, the following are the hardware minimum requirements: Minimum hardware requirements for a Front-end web server for a medium dataset deployment of Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single server and multiple server farm installation for production use 80 GB Minimum hardware requirements for an Application server for a medium dataset deployment of Project Server 2013

34 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single-server and multiple-server farm installation for production use 80 GB Minimum hardware requirements for the SQL Server tier for a medium dataset deployment of Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core (If your dataset size is significantly larger than the medium dataset, we recommend 8 cores.) 16 GB 100 GB Recommended hardware for Project Server 2013 for a medium dataset As a general prescription, you should prepare to handle additional user load and data load by having sufficient computers to add more front-end web servers and Application servers to your topology. The hardware specifications of your front-end web servers and Application servers can remain largely the same. A 4x2x1 topology (four front-end web servers, two Application servers, and one computer that is running SQL Server) should be sufficient for handling the needs of most medium data sets and usage patterns. However, scaling out your Application and front-end web servers will add more load to the SQL Server tier, which you will have to compensate for by adding more memory and CPU resources. The following SQL Server specification should be able to handle the performance needs of most medium datasets. SQL Server hardware recommendations for Project Server 2013 for a medium dataset COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, eight-core, 2.5 GHz minimum per core (If your dataset size is significantly larger than the medium dataset, we recommend 8 cores.) 32 GB 160 GB NOTE - Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. NOTE - RAID 5 should provide a good compromise between reliability, and throughput. Additionally, if the SharePoint Server 2013 instance on which Project Server 2013 is coexisting with also experiences heavy usage (for example, you are not using the instance specifically for Project Server 2013 functionality), we recommend a separation of the ProjectService database and the SharePoint Server 2013SharePoint Server 2016 content databases. This requires you to place them on two dedicated computers that are running SQL Server.

35 Large dataset hardware recommendations in Project Server 2013 The following are the recommended hardware requirements for a Project Server 2013 large dataset scenario. See How datasets affect performance and capacity in Project Server 2013 for more information about how the large dataset size is defined. For large datasets, data load is the biggest concern. At a minimum, for large datasets you will want a topology. The hardware characteristics of the front-end web and Application servers can generally remain the same as those recommended for the small and medium datasets. However, because the SQL Server tier will be the bottleneck, you may find that this constrains your ability to scale out to additional front-end web and Application servers. If data load is the bottleneck, you may find that additional front-end web and Application servers do not produce an improvement in throughput. For a large data set, we recommend that you invest in additional resources on the SQL Server tier of your topology. You can "scale-up" your SQL Server by adding additional RAM, CPU and hard disk resources. The following are the minimum and recommended specifications for the SQL Server tier of a large dataset topology. Minimum requirements for hardware for large datasets in Project Server 2013 Minimum hardware requirements for the SQL Server tier for a large dataset deployment of Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core (If your dataset size is significantly larger than the medium dataset, we recommend 8 cores.) 32 GB 250 GB NOTE - Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. NOTE - RAID 5 should provide a good compromise between reliability, and throughput. Recommended hardware for Project Server 2013 for a large dataset SQL Server hardware recommendations for Project Server 2013 for a large dataset COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, eight-core, 2.5 GHz minimum per core (If your dataset size is significantly larger than the medium dataset, we recommend 8 cores.) 64 GB 300 GB or more NOTE - Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. NOTE - RAID 5 should provide a good compromise between reliability, and throughput. Software requirements for Project Server 2013

36 This section describes the software requirements for Project Server This includes the following: Operating system Database server (SQL Server) SharePoint Server 2013 Software requirements for Project Server 2013 feature usage Operating system Project Server 2013 runs on the following server operating systems: Windows Server 2012(64-bit) Windows Server 2008 R2(64-bit) with a minimum service-pack level of Service pack 1. Supported Windows Server 2012 editions Windows Server 2012, Standard Edition (64-bit) Windows Server 2012, Datacenter Edition (64-bit) Supported Windows Server 2008 R2 editions Windows Server 2008 R2 SP1, Standard Edition (64-bit) Windows Server 2008 R2 SP1, Enterprise Edition (64-bit) Windows Server 2008 R2 SP1, Datacenter Edition (64-bit) Note Server Core installations of Windows Server 2008 R2 are not supported. Important SharePoint Server 2013 and Project Server 2013 are available only in 64-bit editions, and they require 64-bit editions of Windows Server 2008 R2 or Windows Server Windows Server server roles Project Server 2013 requires the following Windows Server server roles on each Application server in the farm: Required server roles for Application servers Application server role Web Server role with Internet Information Services (IIS) 6 Management Compatibility enabled In addition to these server roles, Project Server 2013 also requires that Microsoft PowerShell be enabled. Note Both the server roles and Microsoft PowerShell are configured automatically by the SharePoint Server 2013 prerequisite installation tool if they are not already enabled. Note For more information about Windows Server 2008 R2, see the Windows Server 2008 R2 on Microsoft TechNet.

37 SharePoint Server 2013 Project Server 2013 runs as a SharePoint Server 2013 service application. Therefore, SharePoint Server 2013 Enterprise is a prerequisite for Project Server 2013 installation. Prior versions of SharePoint Server and SharePoint Foundation 2013 are not supported. Note For more information about SharePoint Server 2013 hardware and software requirements, see Hardware and software requirements (SharePoint 2013). Requirements for the database server (SQL Server) For database servers, Project Server 2013 (and SharePoint Server 2013) supports use with the following versions of SQL Server: SQL Server versions supported for Project Server 2013 SQL Server 2012 (64-bit) SQL Server 2008 R2 with Service Pack 1 (SP1) (64-bit) SQL Server 2014 (64-bit) > NOTE - SQL Server 2014 support requires Project Server 2013 with Service Pack 1. The following components of SQL Server are required: Database Engine Analysis Services Management tools Connectivity components The SQL Server Agent service must be running. If you plan to upgrade from a Project Server 2010 environment, be aware that Project Server 2013 does not support SQL Server Note For more information about SQL Server, see the following Microsoft TechNet Home pages: SQL Server 2008 R2 SQL Server 2012 Software requirements for Project Server 2013 feature usage The following table describes software requirements for use of specific Project Server 2013 features that you may want to use. FEATURE REQUIRED SOFTWARE CONFIGURATION NOTES

38 FEATURE REQUIRED SOFTWARE CONFIGURATION NOTES My Tasks (task synchronization with Exchange Server 2013, Project Server 2013, and SharePoint Server 2013) Active Directory Synchronization (Resources and security groups) Reporting Lync presence in Project Web App or Project Professional Server requirements: Exchange Server 2013 Desktop requirements (supported Outlook versions): Outlook 2013 Outlook 2010 Microsoft Office Outlook 2007 Microsoft Office Outlook 2003 Mobile requirements (supported mobile operating system versions): Windows Phone 7.5 or newer iapple: OS 5 or newer Android 2.3 or newer The domain controller must be one of the following operating systems: Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 On premises (supported versions): Excel 2013 Excel 2010 Project Online: Excel 2013 only One of the following: Lync 2013 with Internet Explorer 10, Internet Explorer 9, Internet Explorer 8, Mozilla Firefox (latest released version), or Google Chrome (latest released version). Lync 2010 with Internet Explorer 10, Internet Explorer 9 or Internet Explorer 8. Internet Explorer 9, Internet Explorer 8, Mozilla Firefox (latest released version), and Google Chrome (latest released version) with any Office 2013 application will provide the user a contact card, but no Skype for Business presence. NOTE - Skype for Business presence and contact card do not work in the new Internet Explorer interface in Windows 8.x, but do work on the traditional Desktop Internet Explorer 10. The Work Management Application service must be enabled. Exchange Server 2013 and SharePoint Server 2013 have to be on the same domain together with the Auto Discover server configured and functional. IMPORTANT - For Exchange Server 2013 integration with Project Server 2013, hybrid deployment is not supported. Exchange Server 2013 must be integrated either in an on-premises environment or online. An on-premises integration of Exchange Server 2013 will not support Project Online users. Reporting through the OData service (for both Project Server 2013 onpremises and Project Online) requires Excel For more information about Reporting in Project Server 2013, see Plan reporting and business intelligence in Project Web App. For more information about software requirements for using business intelligence for your reports, see Software Requirements for business intelligence.

39 FEATURE REQUIRED SOFTWARE CONFIGURATION NOTES Workflow editing Requires both of the following: SharePoint Designer 2013 Microsoft Visio 2013 Client requirements for Project Server 2013 When you are planning system requirements for Project Server 2013, you must also consider hardware and software requirements for the client users who need to connect to the server. These client users include the following: Project Professional 2013 users Project Web App users Project Professional client compatibility with Project Server 2013 If you plan to upgrade from an earlier version of Project Server, you must consider whether your current Project Professional clients will be compatible with Project Server PROJECT SERVER VERSION SUPPORTED PROJECT PROFESSIONAL VERSION NOTE Project Server 2013 Project Professional 2016 Project Professional 2013 Project Online Desktop Client Project Server 2010 Project Professional 2010 Office Project Professional 2007 with Service Pack 2 Note that the same clients are supported to connect to Project Server For more information, see Software requirements for Project Server Project Professional 2007 with Service Pack 2 can only connect to Project Server 2010 when backward compatibility mode is enabled on the server. Project Server 2007 Office Project Professional 2007 Plan for these two considerations when planning for Project Professional client connectivity: Project Server 2013 does not provide a "backward compatibility" connectivity feature for any previous Project Professional client versions. Project Professional 2013 does not connect to Project Server Project Professional 2013 installation requirements Project Professional 2013 has the following installation requirements: Project Professional 2013 installation requirements Computer and Processor Memory Hard disk 1 GHz or faster x86/x64 processor with SSE2 instruction set 1 GB RAM (32-bit) 2 GB RAM (64-bit) 2 GB available

40 Operating system Graphics Browser requirements Supported versions: Windows 7 Windows 8 Windows 8.1 Windows 10 Windows Server 2008 Release 2 NOTE - With.NET Framework version 3.5 or 4.0 Graphics hardware acceleration requires DirectX10 graphics card resolution Supported versions: Internet Explorer 11 Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 Mozilla Firefox (latest released version) Apple Safari (latest released version) Google Chrome (latest released version) Visual Reports requirements Office Excel 2007, Excel 2010, or Excel 2013 Office Visio 2007, Visio 2010, or Visio 2013 Note For more information about Project Professional 2013 requirements, see Microsoft Project Professional Project for Office 365 requirements Project for Office 365 is a subscription-based online offering of Project Professional through Office 365. Project for Office 365 has the same system installation requirements as Project Professional. Project Web App requirements for Project Server 2013 For Project Web App in Project Server 2013, you can use any of the following supported web browsers: Supported web browsers for Project Web App Internet Explorer 11 Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 Mozilla Firefox (latest released version) Apple Safari (latest released version) Google Chrome (latest released version) Important Project Web App in Project Server 2013 supports the same web browsers that are supported for SharePoint Server For more information about supported browsers for SharePoint Server 2013, see Plan browser support (SharePoint 2013).

41 Note Project Web App in Office 365 requires the same supported browsers. Project Server 2013 with the Azure platform You can install Project Server 2013 and SharePoint Server 2013 on the Azure platform. For more information, see SharePoint on Azure Infrastructure Services in the Azure library. See also Support and licensing for Azure in SharePoint 2013

42 Planning Project Server and Project Online for business decision makers 12/15/ min to read Edit Online Summary: Learn about the business planning decisions you have to make when you deploy Project Server or Project Online. Applies to: Project Server 2016 Project Web App is the primary interface you use to manage projects and resources in Project Online and Project Server. Project Web App in Project Server 2016 and Project Web App in Project Online are very similar, but there are some key differences that you should be aware of when you decide whether to use Project Server or Project Online. Read this article for an overview of these differences and the factors to consider when you decide which option to choose. We'll also cover key configuration decisions that you'll have to make when you set up Project Web App. In this article, we'll look at business decisions. Also look at the technical decisions you'll need to make. For a feature-by-feature comparison of Project Server and Project Online, see A feature/function comparison of Project Online and Project Server User access in Project Server and Project Online Project Web App offers two methods of user access: SharePoint permission mode This mode uses SharePoint security to provide access to Project Server or Project Online. This mode is simple to use and allows you to provide different levels of access to people with different roles, such as project managers, resource managers, and team members. Project permission mode This mode uses a complex security model that provides very precise control of user access, including customization of permissions for each role and custom roles. This mode takes careful planning to set up and maintain. It's not recommended unless you have a very mature project management office and need to customize user access at a very detailed level. Whereas you can switch between the two modes, doing so requires that you reconfigure all of your permissions. We recommend that you choose the mode that's best for your organization before you configure Project Web App. Generally, unless you have a large and highly complex organization with specific business requirements to finetune what users have access to, we highly recommend that you use SharePoint permission mode. This mode is much easier to set up and maintain. For more information about the two modes and which features are supported in each, see Plan user access in Project Server. Business intelligence in Project Server and Project Online Getting information out of Project Web App is as important as getting information into it. Business intelligence, or reporting, is a big reason why many customers choose Project Web App. There are some important differences between how Project Server and Project Online handle reporting. With Project Server, you can build customized online analytical processing (OLAP) cubes using the data in the Project Web App database. OLAP cubes are not currently available in Project Online.

43 If you're willing to do some additional integration, you can build a hybrid business intelligence solution. You can use Project Online and have your data copied to a data warehouse on-premises or to Microsoft Azure for reporting with on-premises reporting tools. Or you can use Project Server on-premises and use Power BI Desktop to access your Project Web App data and publish reports to the cloud. The following table compares how you can use on-premises and online business intelligence services with Project Server and Project Online. PROJECT SERVER PROJECT ONLINE Cloud business intelligence On-premises business intelligence Keeping it simple Use Power BI Desktop to access your on-premises Project Server data. This requires Power BI and may require some configuration by your IT department. Use SQL Server Reporting Services or PerformancePoint Services for your corporate reporting needs. Use Excel for self-service business intelligence and ad-hoc reporting. Both work without additional configuration needed beyond writing the report. Use OData in Excel or a custom application to access your Project Online data for general reporting. Add Power BI for Office 365 for scheduled data refresh, Power BI Q&A, and other advanced features. Bring your Project Online data into a data warehouse on-premises or in Microsoft Azure where you can use standard corporate business intelligence reporting tools, such as SQL Server Reporting Services. This requires configuration and customization by your IT department. Project Online is designed to use Excel as the primary reporting tool. From Excel, you can connect to the Project Online OData feeds and create PivotTables, PivotCharts, and other reports. You can also use Power BI to easily create reports and visualizations on your Project Web App data. If you have a relatively small organization, and basic reports in Excel or Power BI fit your needs, Project Online is your best choice. Advanced reporting needs If you require advanced reporting tools such as OLAP cubes, PerformancePoint Services, or SQL Server Reporting Services, consider one of the following options: Project Server - With Project Server, you have direct access to the data that you need for advanced reporting. This includes the Project Web App OData feeds and OLAP cubes. Project Online - With Project Online, you can use SQL Server Integration Services to connect to the Project Online OData feed and copy your data into an on-premises data warehouse. From there, you can access the data with PerformancePoint Services or SQL Server Reporting Services. Custom fields and lookup tables in Project Server and Project Online By using Project Web App, you can create custom fields to collect metadata associated with your projects. For example, you can create a field where you store the estimated cost of the project. You can create custom fields for projects, tasks, and resources, and users can input values or choose values from lookup tables that you define. Custom fields are available in the OData feeds in Project Web App, and you can include them in reports that you run on Project Web App data. As you plan your deployment, review your business and reporting requirements, and think about what information you want to capture as part of each project. Your implementation team can set up custom fields to capture this data.

44 Custom fields and lookup tables work exactly the same in Project Server and Project Online. Number of Project Web App instances With both Project Server and Project Online, you can create as many instances of Project Web App as you need. A single instance of Project Web App can host many projects across different departments in your organization. Having multiple instances of Project Web App is useful if you need any of the following: Security isolation for governance or other reasons Different sets of users or groups Different calendars Different timesheet standards If you don't need more than seven instances of Project Web App, consider using Project Online. See also IT Pro Planning for Project Server Project Online Service Description

45 Planning Project Server and Project Online for technical decision makers 12/15/ min to read Edit Online Summary: Learn about the technical planning decisions you have to make when deploying Project Server or Project Online. Applies to: Project Server 2016 Project Web App in Project Server 2016 and Project Web App in Project Online are very similar, but there are some key differences that you should think about when deciding whether to use Project Server or Project Online. Read this article for an overview of the technical differences and what to consider when deciding on which option to choose. We'll also cover key configuration decisions that you'll have to make when setting up Project Web App. In this article, we'll look at technical decisions. Also look at the business decisions you'll need to make. For a feature-by-feature comparison of Project Server and Project Online, see A feature/function comparison of Project Online and Project Server User access in Project Server and Project Online The biggest decision that you'll have to make about security in Project Server or Project Online is which security mode to use. Security modes Project Web App offers two security modes: SharePoint permission mode This mode uses SharePoint security to provide access to Project Server or Project Online. This mode is simple, and you can use it to provide different levels of access to different groups of people. Project permission mode This mode uses a complex security model that provides very precise control of user access. This mode takes careful planning to set up and maintain. For each Project Web App site that you have, you need to decide which of the two security modes you want to use. For more information about the two modes and which features are supported in each, see Plan user access in Project Server. Security groups In both security modes, you give your users access to features by adding them to groups. In both modes, Project Web App creates the following seven default groups: Administrators Portfolio Managers Portfolio Viewers Project Managers Resource Managers Team Leads

46 Team Members In SharePoint permission mode, these are created as SharePoint security groups in the Project Web App site collection. In Project permission mode, a separate security user interface is added to the PWA Settings page, containing these groups and other security settings. As part of your planning process, you should decide which users to add to each group and how you want to manage those groups. Default group permissions in Project Server 2013 lists the permissions that users in each group have. In SharePoint permission mode, these permissions are static and can't be changed. In Project permission mode, they're fully customizable. In both modes, you can synchronize the groups with Active Directory groups. You do this by using Active Directory Synchronization in Project permission mode, and by simply adding the Active Directory group you want to the SharePoint group in SharePoint permission mode. Business intelligence in Project Server and Project Online There are some important differences between how Project Server and Project Online handle reporting: Project Server - In Project Server, you have direct access to Project Web App data in the content database (if your Project Web App site has its own content database), and you can query the reporting schema using Excel or more advanced reporting tools such as SQL Server Reporting Services or PerformancePoint Services in SharePoint Server With Project Server, you can also build customized OLAP cubes using the data in the Project Web App database. Project Online - Direct database access is not possible because Project Online is hosted in a Microsoft datacenter. You must access your Project Web App data using one of the provided OData feeds. OLAP cubes are not currently available in Project Online. Beyond this, you can combine cloud and on-premises BI solutions by copying your Project Online data into a data warehouse on-premises or in Microsoft Azure, or by accessing your on-premises Project Server data from Power BI and publishing reports to the cloud. The following table shows a high-level comparison of how on-premises and online BI services can be used with Project Server and Project Online. PROJECT SERVER PROJECT ONLINE Cloud BI Use Power BI Desktop to write reports by accessing Project Web App data in the content database or using the OData feed. These reports can be shared by publishing them to the cloud. Use Excel to access the Project Online OData feeds. Save reports for your users to your Project Online reporting library. Optionally, use Power BI reports and data visualizations.

47 PROJECT SERVER PROJECT ONLINE On-premises BI For corporate BI, use SQL Server Reporting Services or PerformancePoint Services to report directly on the reporting data in the content database or online analytical processing (OLAP) cubes. (Requires no more than one instance of Project Web App per content database.) For self-service BI, use Excel to access the Project Server OData feeds or OLAP cubes. Use SQL Server Integration Services to create a data warehouse on-premises or in Microsoft Azure. Use SQL Server Reporting Services or PerformancePoint Services to report from that. Setting up reporting in Project Online is the easiest option to configure. The OData feeds for Project Web App work as soon as you set up Project Web App. Setting up reporting in an on-premises environment is more involved. If you want to access the Project Web App in the content database, you need to follow a series of steps that includes setting up Office Online Server andsecure Store. If you want to copy Project Online data into an on-premises data warehouse, you need to use SQL Server Integration Services and create a custom solution. Of all the reporting options for Project Web App this requires the most up-front work from your IT department or BI specialists. However, it does allow you to use Project Online even if you have business requirements for advanced reporting in an on-premises database. Because pretty much any reporting need can be met using Project Online, either by itself or with a custom data warehouse using SQL Server Integration Services, we recommend Project Online as your first choice unless you have other business needs that require Project Server on-premises. Workflows in Project Server and Project Online Workflows enforce your business processes and provide a structured way for projects to move through the various steps dictated by those processes. You can set up a workflow to do a variety of actions based on the user input, including sending s, assigning tasks, and waiting for specific project actions. While you can use Project Server or Project Online without using workflows, by using workflows, you can provide a basic structure to how projects are managed and how your project team interacts with them. As part of your planning process for Project Web App, be sure to plan how you want to use workflows to help you manage your projects. Custom fields in Project Server and Project Online By using Project Web App, you can create custom fields that you can use to collect metadata associated with your projects. Custom fields are available in the OData feeds in Project Web App and can be included in reports that you run on Project Web App data. Custom fields work the same in Project Server and Project Online. There are two types of custom fields: local andenterprise. Local custom fields are created and maintained in Project Professional. They are specific to a particular project. Enterprise custom fields are created and maintained in Project Web App and are available to all projects in Project Web App. You can create enterprise custom fields that are optional or required. Local custom fields The main thing to consider when you use local custom fields is a naming convention. If you plan to use fields for the same purpose across multiple projects, be sure to give them the same name. By using the same name, you can

48 use the fields consistently in reports among subprojects within a master project. Enterprise custom fields Consider the following when you plan your enterprise custom fields: You can configure enterprises custom fields to be controlled by workflow. You can make enterprise custom fields optional or required. So if you want to be sure that you collect certain information at different stages of your workflow, for example, you can create custom fields that are required, and the user will have to fill them in before they can advance the workflow. While local custom fields are specific to a project, it's important to realize that enterprise custom fields are available in all projects in Project Web App. So when you create a custom field, consider how many projects you'll use it in to determine if you should make it a local or enterprise custom field. Custom fields and system performance There are some circumstances where using custom fields can cause a noticeable reduction in performance, both in Project Server and in Project Online. Keep these in mind when you plan your custom fields. Formulas in custom fields use system resources for their calculations. With local custom fields, this occurs in Project Professional. With enterprise custom fields, this occurs in Project Server or Project Online. Normally, these calculations happen in the background and aren't noticeable to the user, but with many custom fields with complex formulas, you might start to see a reduction in performance. Similarly, lookup tables with large numbers of values can have a noticeable performance impact. Lookup tables with dozens or hundreds of options can cause a lag in performance. See also IT Pro Planning for Project Server

49 Plan user access in Project Server 12/15/ min to read Edit Online Summary: Learn about the user access permission modes available in Project Web App. Applies to: Project Server 2016, Project Server 2013 Project Server offers two security modes for controlling the kind of access that users have to sites and projects: SharePoint permission mode In this mode, a special set of SharePoint security groups are created in sites associated with Project Server. These groups give users varying levels of access to projects and Project Server functionality. Project permission mode In this mode, Project Server provides customizable security groups and other functionality that is distinct from SharePoint groups. In both security modes, the SharePoint site administrator for the Project Web App site is also a Project Web App administrator. What features are available in each Project Web App permission mode? Use this table to compare the features available in each security mode. Comparison of features for security modes in Project Server FEATURE SHAREPOINT PERMISSION MODE PROJECT SERVER PERMISSION MODE Use a single set of security groups across Project Web App and SharePoint Server. Permissions inheritance for PWA and Project Sites Direct authorization against Active Directory security groups Claims-based authorization Manage authorization by role-based groups Extensible and customizable User delegation Ability to secure work resources Impersonation Security filtering using the Resource Breakdown Structure

50 FEATURE SHAREPOINT PERMISSION MODE PROJECT SERVER PERMISSION MODE Custom Security Categories When you've determined which permission mode you want to use, more information is available: For information about SharePoint permission mode, see Plan SharePoint groups in Project Server. For information about Project Server permission mode, see Plan groups, categories, and RBS in Project Server. New Project Web App instances use the SharePoint permission mode by default. If you have more than one instance of Project Web App, each site can use a different permission mode. Changing Project Web App permission modes In an on-premises installation of Project Server, the permission mode can be changed for a given instance of Project Web App by using the Set-SPProjectPermissionMode Microsoft PowerShell cmdlet. For more information, see Set-SPProjectPermissionMode. In Project Online, the mode can be changed in the Microsoft Office 365 portal site. For more information, see Change permission management in Project Online. Caution Switching between SharePoint permission mode and Project Server permission mode deletes all security-related settings. If you switch from SharePoint permission mode to classic Project Server permission mode, you have to manually configure your security permissions structure in Project Server. Switching from Project Server permission mode back to SharePoint permission mode deletes your security permissions information from Project Server.

51 Plan SharePoint groups in Project Server 12/13/ min to read Edit Online Summary: Plan users and groups for Project Server in SharePoint permission mode. Applies to: Project Server 2016, Project Server 2013 SharePoint permissions mode creates SharePoint groups that directly correspond to the default security groups found in Project Server permission mode. The following table describes the Project Server SharePoint groups and what user functionality they enable in Project Web App. SHAREPOINT GROUP Administrators Portfolio Viewers Project Managers Portfolio Managers Resource Managers Team Leads Team Members FUNCTION Users have all global permissions as well as category permissions through the My Organization category. This allows them complete access to everything in Project Web App. Users have permissions to view Project and Project Web App data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks. Users have permissions to create and manage projects. This group is intended for project owners who assign tasks to resources. Users have assorted project-creation and team-building permissions. This group is intended for high-level managers of groups of projects. Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data. Users have limited permissions around task creation and status reports. This group is intended for persons in a lead capacity that do not have regular assignments on a project. Users have general permissions for using Project Web App, but limited project-level permissions. This group is intended to give everyone basic access to Project Web App. These Project Server SharePoint groups have the same global and category permissions that are assigned to them in Project Server permission mode. In SharePoint permissions mode, you cannot create additional custom groups, categories, Resource Breakdown Structure (RBS) nodes, or edit the default permissions assigned to any of these objects. Adding users to Project Web App in SharePoint permission mode There are two methods of adding users to the SharePoint groups: Add user accounts individually

52 Add one or more Active Directory groups You can use one or both of these methods for each group. For information on how to add users and Active Directory groups to SharePoint groups, see Share a site. Adding individual users to SharePoint groups When you add individual users to one of the SharePoint groups, that user is synchronized to Project Web App automatically. User synchronization runs on a SharePoint timer job, by default every ten minutes. Using Active Directory groups to add users to SharePoint groups When you add Active Directory groups to one of the Project Server-specific SharePoint security groups, the users are not automatically added to the list of users in Project Web App. Each user is individually added to Project Web App the first time she or he accesses the Project Web App site. Because users in Active Directory groups do not appear on the list of Project Web App resources until they have accessed the Project Web App site, we recommend that you configure Active Directory synchronization in Project Web App to prepopulate your resource list. This allows you to have a complete resource list and to assign work to resources before they have accessed the Project Web App site. See also Plan groups, categories, and RBS in Project Server

53 Plan groups, categories, and RBS in Project Server 12/13/ min to read Edit Online Summary: In Project Server permission mode, Project Web App security is based on users, groups, and categories. Applies to: Project Server 2016, Project Server 2013 This article addresses planning for groups and categories in a Project Server deployment. If you are using SharePoint permission mode as your security model, see Plan SharePoint groups in Project Server. In this article: Permissions in Project Web App Groups in Project Web App Categories in Project Web App Security templates in Project Web App Resource Breakdown Structure in Project Web App Permissions in Project Web App A permission is the authority to perform a specific action within the context of Project Server. You canallow, Deny, or not configure each permission in Project Server. For example, the Change Password permission can be allowed or denied for any given user or group. There are two types of permissions in Project Server: Global Permissions grant users and groups the ability to perform actions throughout an instance of Project Web App. Global Permissions are assigned on a user or group level. Category Permissions grant users and groups the ability to perform actions on specific projects and resources. Category Permissions are assigned on a category level. Permissions can be set in a number of different places within Project Web App. You can allow or deny permissions by selecting the check boxes in the Allow and Deny columns. If neither the Allow nor the Deny check boxes are selected, the default state is Not Allow. The Not Allow state does not prevent users from accessing the feature associated with the permission if they are granted permission in some other way. For example, a user might belong to one group for which permission is not configured (Not Allowed), but might be granted permission by means of membership in a group for which the permission is allowed. However, if the permission is explicitly denied anywhere, permission is denied everywhere for a particular user or group. You can configure all Project Server permissions by choosing Project Web App Settings from the Project Web App Settings menu. Permissions can be configured in the following ways: Allow Enables users or group members to perform the actions associated with the permission. Deny Prevents a user or group from performing the actions associated with the permission. Use caution when denying permissions. Note that if a user is denied a specific permission, the deny setting supersedes any Allow settings that might apply to other groups to which the user belongs. No permissions are set to Deny by default. Not Allow If you select neither Allow nor Deny for a permission, the default state is Not Allow. If a user

54 belongs to more than one group, and a permission is set to Not Allow for one group and is set to Allow (but not Deny) for another group, then the user is allowed to perform the actions associated with the permission. 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. Note The Deny setting enables you to deny access to functionality, because this setting overrides the Allow setting. Therefore, use caution when selecting the Deny check box. Select the Deny check box to prevent a user from outside the organization from accessing Project Server security objects or to deny functionality to a user or group). For organizations that include a large number of users, assigning and administering permissions on an individual basis can be an overwhelming task. You can use groups to assign permissions to multiple users with a single action. Create the groups and define the set of permissions to associate with the groups as part of your initial Project Server deployment planning process, before you assign users to groups and groups to categories. After you define groups, the permissions associated with the groups, and group memberships, the day-to-day administration of users, groups, and categories involves adding users to or removing users from security groups. This helps to reduce the volume of day-to-day administrative tasks required, and can simplify troubleshooting permissions issues. Groups in Project Web App Groups contain sets of users who have similar functionality needs. For example, every project manager in a particular division within your organization may need the same set of Project Server permissions, while executives or resource managers might have different needs. Define your groups by identifying common needs based on the areas of Project Web App to which users in your organization need access. After you define your groups, you can add users to the groups and grant permissions to the groups; permissions assigned to groups apply to all of the users that the group contains. Using groups to control Project Web App permissions simplifies security administration in Project Web App. Group memberships can change frequently, but the access requirements for groups change infrequently. Note Group membership consists of users only. Groups cannot contain other groups. Users can belong to multiple groups according to their role in the organization and their access requirements. The following default groups are available in each instance of Project Web App that is in Project Server permission mode. Each is assigned a set of predefined categories and permissions. GROUP Administrators DESCRIPTION Users have all global permissions as well as all category permissions via the My Organization category. This allows them complete access to everything on a given instance of Project Web App.

55 GROUP Portfolio Viewers Portfolio Managers Project Managers Resource Managers Team Leads Team Members DESCRIPTION Users have permissions to view project and Project Web App data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks. Users have assorted project-creation and team-building permissions. This group is intended for high-level managers of groups of projects. Users have most global and category-level project permissions and limited resource permissions. This group is intended for users who maintain project schedules on a daily basis. Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data. Users have limited permissions around task creation and status reports. This group is intended for people in a lead capacity who do not have regular assignments on a project. Users have general permissions for using Project Web App, but limited project-level permissions. This group is intended to give everyone basic access to Project Web App. All new users are added to the Team Members group automatically. Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group. Categories in Project Web App Categories are collections of projects, resources, and views. Categories define the scope of the information accessible to a given user. A category is similar to a group in that it provides permissions to users. Unlike Global Permissions, Category Permissions are related to specific projects and resources. Additionally, categories include project and resource filters that can be used to determine which projects and resources the specified permissions apply to. Groups and Categories are associated with each other to provide a complete set of permissions for each user. Each Group can be associated with one or more Categories and each category can provide a different set of project- and resource-level permissions on the projects in that category for the members of that group. Each Project Web App instance includes the following default categories: CATEGORY My Direct Reports My Organization DESCRIPTION Allows users permission to approve timesheets for their direct descendants in RBS. This category is intended for managers who need the ability to approve timesheets. Contains all projects and resources and allows various levels of category permissions depending on associated group management. It also provides full access to all views. This category is intended to allow users to have visibility into everything on the Project Web App instance.

56 CATEGORY My Projects My Resources My Tasks DESCRIPTION Filtered to allow category permissions to users who own projects or are status managers on a project, are assigned as a resource to a project, or whose descendants in RBS are assigned to a project. This category is intended to allow users to have visibility into all project with which they or their descendants in RBS are associated. Allows most resource-level category permissions, filtered on resources who are descendants of the user in RBS. This category is intended to allow users to manage their resources as delineated in the RBS structure. Allows users to see projects to which they are assigned. This category is associated with the Team Members group and is intended for everyone to have visibility into the projects to which they are assigned. You can create custom categories to provide new ways to access data for projects, resources, and views. A large number of categories can be complex to administer. We recommend that you use categories sparingly. Security templates in Project Web App Security templates are predefined sets of permissions. Use security templates to simplify the process of granting permissions to groups of users who need access to the same data. Each Project Web App instance includes the following default security templates: Administrator Portfolio Viewer Portfolio Manager Project Manager Proposal Reviewer Resource Manager Team Lead Team Member Security templates provide a means for you to quickly apply or reset predefined permission profiles to new or existing users, groups, and categories. By applying security templates, you can easily standardize the permissions that you assign according to users' role in the organization. The default security templates align with the predefined groups in Project Web App. You can customize these security templates and create new security templates according to your needs. Note When you change the settings for a security template, the changes are not automatically applied to the users and groups that the template was applied to. Creating custom security templates requires planning. You must first identify the common Project Web App usage patterns in your organization that are not reflected in the default security templates. This helps you to identify your requirements for custom security templates. Then, determine the permissions that the users who

57 share the common Project Web App usage patterns require. This defines the security template. Next, determine the set of projects, resources, views, and so on, that the users and groups require access to; this defines the security category. Create the custom security template and apply it to the group of users that share common usage patterns. Resource Breakdown Structure in Project Web App The Resource Breakdown Structure (RBS) is a hierarchical security structure typically based on the management reporting structure of your organization, although it can also be structured in other ways. The RBS can be an important element in your Project Web App security model when it is used to define the reporting relationships among users and projects in your organization. When you specify an RBS value for each Project Web App user, you can take advantage of the dynamic security options that can be defined for each security category. The RBS structure is defined by adding values to the RBS custom lookup table that is built in to Project Web App. Once you define the structure, you can assign RBS values to individual users by setting the RBS property in the user's account settings page. Once the RBS is configured, Categories can use RBS codes to dynamically determine which projects and resources particular users can view or access. The following tables list the security options that use RBS that are available in each Category. Security options for projects OPTION The user is the Project Owner or the User is the Status Manager on assignments within that project The user is on that project's Project Team The Project Owner is a descendant of the User via RBS A resource on the project's Project Team is a descendant of the User via RBS The Project Owner has the same RBS value as the User DESCRIPTION Users with permissions in the category where this option is selected can see projects on which they are a Project Owner or a Status Manager Users with permissions in the category where this option is selected can see projects on which they are a resource Users with permissions in the category where this option is selected can see projects owned by their descendants in the RBS Users with permissions in the category where this option is selected can see projects on which their descendants in the RBS are a resource Users with permissions in the category where this option is selected can see projects owned by other users with the same RBS value Note The first two options ( The user is the Project Owner or the User is the Status Manager on assignments within that project and The User is on that project's Project Team) are not related to the RBS, but they do offer a similar method of filtering which projects are visible to a user. Security options for resources OPTION DESCRIPTION

58 OPTION The User is the resource They are members of a Project Team on a project owned by the User They are descendants of the User via RBS They are direct descendants of the User via RBS They have the same RBS value as the user DESCRIPTION Users with permissions in the category where this option is selected can see themselves as a resource Users with permissions in the category where this option is selected can see resources assigned to projects that they own Users with permissions in the category where this option is selected can see their descendants in the RBS Users with permissions in the category where this option is selected can see their direct descendants in the RBS Users with permissions in the category where this option is selected can see other users with the same RBS value Note The first two options ( The User is the resource and They are members of a Project Team on a project owned by the User) are not related to the RBS, but they do offer a similar method of filtering which resources are visible to a user. The options in the tables above can be configured when you create or modify a Category. See also Video series: How security permissions work in Project Server

59 IT Pro Planning for Project Server 12/15/ min to read Edit Online Summary: Learn about deployment planning. Before you install Project Server, be sure you have reviewed the information in these articles. The following articles provide information about planning for Project Server deployment. CONTENT Determine project management requirements in Project Server Determine the number and types of users that require access to Project Server Plan the project life cycle in Project Web App Plan reporting and business intelligence in Project Web App DESCRIPTION It is important to determine the project management needs and requirements for your organization. Your configuration will vary according to the kind of work that your organization performs and whether you use Project Server for time tracking, collaboration, or portfolio management. The number and types of users in your organization who use Project Server features have a direct effect on the scalability and performance needs of your organization. Learn how to plan projects, resources, and custom fields for new projects, and how to archive completed projects in Project Web App. This article describes the options available for creating custom reports of Project Web App data. See also Plan for SharePoint Server 2016

60 Determine project management requirements in Project Server 12/13/ min to read Edit Online Summary: Learn about Project Server feature usage for Enterprise Project Management, timesheet, and demand management scenarios. Applies to: Project Server 2016, Project Server 2013 It is important to determine the project management needs and requirements for your organization. Your configuration will vary according to the kind of work that your organization performs and whether you use Project Server for time tracking, collaboration, or portfolio management. After you characterize the typical projects for your organization, determine which Project Server scenarios that you have to support. Characterize your projects Understanding the characteristics of the projects in your organization enables you to plan your Project Server configuration. The following characteristics have a significant effect on your configuration: The number of projects that your organization is working on at a particular time The size of your projects, which varies with the number of tasks and assignments that your projects include The length of time that is required to complete a project The number of team members that are assigned tasks in projects Most organizations manage projects that vary in size and duration, but the degree to which they vary is a function of the size of the organization and the kind of work that it performs. For example, a large consulting company might manage several thousand projects that range from small, 10-task projects that last two weeks to large projects that include 1,500 tasks and last for over a year. Organizations typically have many projects that range in size from small to medium to large. For planning, make sure that you can adequately support the kind of project that your organization works on most frequently. Determine your Project Server scenario Your project management needs and requirements vary according to the kind of work that your organization performs. As part of your configuration planning process, determine which scenario that you need to support. For example, you can use Project Server to support the following kinds of scenarios: Enterprise Project Management Time tracking Demand management Using Project Server for Enterprise Project Management The Project Server scenario for EPM applies to a large organization whose area of focus is top-down planning driven through the Project Management Office (PMO). This scenario is more frequently seen in the product development and manufacturing markets. It has the following characteristics: A small number of large projects that are often related

61 Focus on the PMO Extensive use of Project Professional 2016 Work Tracker usage Critical considerations for this kind of deployment include the following: The level of detail to track Using leveling as a process How to prioritize capacity How to use skill tracking In this scenario, client usage is as follows: CLIENT APPLICATION RATE OF USAGE Project Professional Project Web App High High In this scenario, server usage is as follows: PROJECT WEB APP FEATURE RATE OF USAGE Work Tracker Programs Timesheets Portfolio management Master projects Project workspaces Risk management Issues management Document management Resource management Task management High High Medium Medium High Low Medium High Medium Medium Medium Using Project Server for time tracking The Project Server scenario for professional services/timesheet deployment can apply to a large organization that wants to use Project Server mainly to capture and report time. In this scenario, employees and contractors use Project Server timesheet functionality to submit hours worked on tasks during specific time periods. This scenario has the following characteristics:

62 Minimal use of Project Professional Time and material billing A large number of projects that have fairly few tasks A predictable peak period of usage that corresponds to scheduled timesheet entry in Project Web App Organizations that support this scenario typically use a limited set of Project Professional features to track time and costs by using timesheets to capture information. This scenario presents scalability issues, because, when many timesheets are submitted in a short period of time, system resources can become severely strained. Critical considerations for this kind of deployment include the following: What time classifications to use What time periods to use Calendars and overtime setup What fiscal periods to use Source of cost data Custom field configuration process control custom fields vs. reporting custom fields Currency configuration Auditing There are additional factors that can be affected by the processes that are used within your organization, including the following: Types of usage What the project update cycle is What the reporting cycle is In this scenario, client usage is as follows: CLIENT APPLICATION Project Professional Project Web App RATE OF USAGE Medium High In this scenario, server usage is as follows: PROJECT WEB APP FEATURE Work Tracker Programs Timesheets Portfolio management Master projects RATE OF USAGE High Low High Low Low

63 PROJECT WEB APP FEATURE Project workspaces Risk management Issues management Document management Resource management Task management RATE OF USAGE Low Low Low Low High Medium Using Project Server for Demand Management The Project Server scenario for Demand Management deployment can apply to any medium-to-large organization that wants to use Project Server to manage project portfolios. These organizations typically have the following characteristics: A large number of projects that have many assignments A high percentage of project managers Frequent use of Project Professional Organizations that support this scenario typically use the breadth of Project Server features that include timesheets, document libraries, issues, risks, the Enterprise Global Template, and the Enterprise Resource Pool. The organization to which this scenario can apply can be as small as a medium-size organization (or a department in a larger organization) whose users all share the same physical location on the same LAN, or it can be a large organization whose users work in several different physical locations. These organizations use Project Professional and Project Web App daily to publish or update projects to Project Server, and they use Project Web App to view assignments; report actuals; and access documents, issues, and risks. Additionally, these organizations generate online analytical processing (OLAP) cubes weekly. Critical considerations for this kind of deployment include the following: Level of resource data to track What project nomination process to use What kind of review process to use What the report cycle will be Workflow requirements What kind of work to track Who manages the process What demand is captured In this scenario, client usage is as follows:

64 CLIENT APPLICATION Project Professional Project Web App RATE OF USAGE Medium High In this scenario, server usage is as follows: PROJECT WEB APP FEATURE Work Tracker Timesheets Portfolio management Programs Administrative projects Collaboration Document management Risk management Issues management Resource management Project workspace sites RATE OF USAGE Low Medium High Low Low Medium Medium Medium Medium Medium Medium

65 Determine the number and types of users that require access to Project Server 12/13/ min to read Edit Online Summary: Learn about the different types of users that require access to Project Server and Project Web App. Applies to: Project Server 2016, Project Server 2013 The number and types of users in your organization who use Project Server features have a direct effect on the scalability and performance needs of your organization. Number of Project Server users When you determine the number of Project Server users that your organization needs to support, also consider the maximum number of concurrent users. This is especially critical if your organization plans to support the time tracking scenario. It is helpful to categorize users to determine the different types that you need to support, as well as how many of each type. For example, project managers who use Project Professional create the greatest load on the system; viewers create the smallest amount of load. Types of Project Server users The types of users that you need to support, and the percentage of each compared to the total number, affects the configuration decisions that you make during your planning process. Each user type places a load on the system. The most common user types are as follows: Project managers Resource managers Team members Portfolio viewers Administrators Project managers Project managers are responsible for overseeing and completing projects, sometimes coordinating with other project managers and resource managers in the organization. Project managers use Project Professional to do the following: Create and publish projects to Project Web App Modify projects based on feedback Assign team members to project tasks Track progress by incorporating task updates from team members Determine target and actual project timelines and costs Resource managers Resource managers are responsible for managing resources and defining skills based on capabilities. They work with project managers and other resource managers to ensure that qualified resources are assigned to tasks in

66 projects. Resource managers use Project Web App to do the following: View workload and availability by project over time View workload and availability by resource over time Add team members to project teams Post issues and upload documents Use Portfolio Modeler to determine resource availability Modify resource skills and other codes Team members Team members are resources who are assigned to tasks in projects. A team member typically works on multiple projects at any given time and is responsible for completing tasks according to a schedule. Team members typically use Project Web App rather than Project Professional. Team members use Project Web App to do the following: Meet deadlines by identifying current and upcoming tasks to prioritize daily work Report time spent working on tasks by entering progress in timesheets Delegate and add tasks Record and respond to project-related issues and risks Link issues to tasks Submit status reports Work collaboratively with other team members on project-related documents Team members use Outlook to do the following: View assigned tasks Report on assigned tasks Portfolio viewers A portfolio viewer is a user who uses Project Web App to view status or reporting on a project or multiple projects. For example, a portfolio viewer can oversee several different projects that are managed by different project managers to gain an overall perspective on schedule and budget. Portfolio viewers use Project Web App to do the following: View project and resource reports in Portfolio Analyzer Submit issues to project and resource managers Administrators Administrators deploy and manage Project Server and related applications. These users manage access to the server. Administrators use Project Web App to do the following: Define timesheet views Lock reporting periods and actuals in timesheets Create standardized reports for Portfolio Analyzer views Add team members to, and delete team members from, the Enterprise Resource Pool

67 Plan the project life cycle in Project Web App 12/13/ min to read Edit Online Summary: Learn how to plan projects, resources, and custom fields for new projects, and how to archive completed projects in Project Web App. Applies to: Project Server 2016, Project Server 2013 There are many methodologies and systems that effectively manage a project life cycle. This article does not advocate for any one of these over another. This article is written for Project Server administrators, and it provides a list of project creation, maintenance, and archival activities. These tasks are general and will be the same, or at least similar, regardless of the methodology being used by your organization. Planning these activities can help ensure that projects are being managed in a way that is consistent with the purpose of your organization and can foster a satisfactory experience for the end user. This article alerts those who are responsible for planning the deployment and configuration of Project Server that some choices will have to be made that relate to these features. Projects have many ways of moving from concept to reality. Sometimes the process is informal and may be the result of a brainstorm on a whiteboard that happened in under an hour. Other times a project is created after years of study and careful analysis. If it is not planned and managed, this creation process can become chaotic. This chaos can cost your organization in many ways: reduced efficiency, misallocated resources, misaligned priorities, duplication of effort, conflicting approaches, and missed opportunities, to name a few. What follows are some key things to consider when you are using Project to create projects for your organization. Plan to migrate task list projects into Project Web App Project Server provides the ability to import projects that were created by using SharePoint lists into an instance of Project Web App. This functionality allows you to quickly start projects and manage them simply while they remain small. As they grow in scope, you can gradually migrate them to become full Project Server projects. Project Server supports only a single instance of Project Web App per site collection. As you plan SharePoint task list projects, consider which site collection that you want to create them in so that projects that are related to each other can be imported into the same instance of Project Web App. We also recommend that you develop guidelines for your organization for how long you want to manage projects in a SharePoint list before you import them into Project Web App. Plan resources in Project Web App Enterprise resources are the people, equipment, and materials that are used to complete tasks in an enterprise project. Enterprise resources are part of your organization's pool of resources and are stored centrally in each instance of Project Web App. You can create the Enterprise Resource Pool that project managers will use when assigning resources to tasks in projects by adding resources to the Enterprise Resource Pool or by importing resources. You should define the contents of the Enterprise Global Template before you add resources to the Enterprise Resource Pool. Before you can properly create and maintain the Enterprise Resource Pool for your organization, you must carefully define and document your Enterprise Resource custom fields and create them. In addition, for large organizations, initially populating the Enterprise Resource Pool is just as important as the process of keeping the Enterprise Resource Pool accurate and up-to-date. Tracking significant changes to the resource information that is stored and managed in the Enterprise Resource Pool can be a full-time activity

68 Before you create your Enterprise Resource Pool for Project Web App, you must determine your starting point. The process of adding resources to the Enterprise Resource Pool varies according to whether you are: Starting with new projects Minimal preparation is necessary for this scenario. The process is simplified if you can gather all required resource information in a single document. You could make a list on paper. Then you would import your identified resources from Active Directory, or from a membership store if you were using forms authentication. Alternatively, you can gather this information by using Excel. Then you would import the resulting spreadsheet into Project Professional and save it to Project Web App. Creating the enterprise resource pool In this scenario, you are creating the Enterprise Resource Pool in Project Professional. Using Project Professional, connect to Project Web App and check out the Enterprise Resource Pool. Enter the resources and save the Enterprise Resource Pool. Plan custom fields in Project Web App Project Web App includes lookup tables and fields that you can customize. A custom field can contain information about a task, resource, or assignment. In Project Web App, fields that can contain customized data are text, flags, numbers, dates, cost, start and finish dates, and durations. You can customize these fields to obtain the information you want using formulas, specific value calculations, or graphical indicators. You can write your own formulas, including references to other fields, to be calculated in a custom field. You can create a list of values for a custom field to ensure fast and accurate data entry. You can display a graphical indicator in a custom field instead of the actual data. That way, you can quickly see when the data in that field meets certain criteria, such as when the data exceeds a specified range or when resources are over-allocated. You can also create a hierarchical structure of custom fields for information in your project. For instance, you might want to associate your company's cost codes with your project data. After you create this structure and apply these custom fields to your data, you can easily use them to filter, sort, and group project data. In Project Web App there are two types of custom fields local and enterprise. Local custom fields are used by the project manager within the scope of a particular project. Enterprise custom fields are used by the Project Management Office (PMO) to collect data for rollup reporting across the organization. For enterprise task and project custom fields, Project Web App supports the notion of scoping to a specific program (collection of projects). In this way, an enterprise custom field can be defined that applies to a subset of projects. (More information on Custom fields in Project Server and Project Online.) Retire projects from Project Web App There are certain activities that you should consider when retiring projects. Doing some basic clean-up when a project is retired can help to improve Project Server performance. Also, you can secure projects to ensure that only those who need the information for example, for historical purposes can see the projects. Deleting other enterprise objects that are not being used, such as resources and assignments, can help to prevent degradation of server performance. Plan archiving in Project Web App A number of enterprise objects can be backed up in Project Web App: Projects Enterprise Resource Pool and Calendars Enterprise Custom Fields Enterprise Global View Definitions

69 System Settings Category and Group Settings Backing up these objects allows you to selectively restore specific items, and you can retain multiple versions of these items. Backups are done on the Project Server Settings page in Project Web App. There are two methods available: Schedule Backup Administrative Backup Administrative Backup allows you to back up enterprise objects at any time. Schedule Backup, as the name implies, allows you to back up enterprise objects daily at a scheduled time. We recommend that you back up your enterprise objects regularly and, if scheduled, at a time when server utilization is low. When an object is backed up, it is saved to an archive area in the SharePoint content database where the Project Web App resides. When a project is complete, there are a few options available for retiring the project. Delete the enterprise objects from Project Web App but retain the archived copy. Delete enterprise objects completely and rely upon database backups for archival. Place the project in a special Project Web App category that denies access to all but a few users. Placing projects in a special Project Server category To allow only certain users to view a retired project, you can create a special Project Web App category for that purpose. Add the project and all users whom you do not want to have access to the project and set all of their permissions to deny. For more information about Users, Groups, and Categories, see Plan groups, categories, and RBS in Project Server. Note To create a category, Project Web App must be in Project Server permission mode. Plan cleanup in Project Web App Deleting unused enterprise objects when a project is completed can help to prevent degradation of server performance. It is particularly beneficial for long term server performance to delete assignments. It is also a good idea to delete resources if they are no longer being used in the enterprise. Deleting unused enterprise objects when a project is completed also saves disk space on your database server.

70 Plan reporting and business intelligence in Project Web App 12/15/ min to read Edit Online Summary: Plan reporting on Project Web App data by using business intelligence tools in SharePoint Server Applies to: Project Server 2013 In Project Server 2013, project information is stored in the Project Web App database. This information can be queried by any reporting tool that can connect to a SQL Server database. The data is also available through an OData feed. The data available for reporting includes timesheet custom fields, project properties, and portfolio planner and optimizer data. Project Server can also generate online analytical processing (OLAP) cubes containing this information. Each instance of Project Web App includes a set of sample reports and templates. These reports are contained within Excel 2013 workbooks and are designed to be used with Excel Services in SharePoint Server Reports in Project Web App that use Excel Excel reports are data-connected spreadsheets that you use to visualize the data retrieved from the Project Web App database or the associated OLAP databases. In Excel 2013, you can present data in Pivot Tables, or Pivot Charts, and have access to additional visualization features. The sample reports included with Project Web App use Office Data Connections to access and retrieve data from the Project Web App database and OLAP databases. Dashboards in the Project Web App Business Intelligence Center You can build dashboard pages in the Project Web App Business Intelligence Center by using Web Parts to display Project Web App data. Using Web Parts, you can present Project Web App data by using several different options: Excel Services SQL Server 2012 Power Pivot for SharePoint Server 2013 Power View for SharePoint 2013 SQL Server Reporting Services (SSRS) 2005 or 2008 PerformancePoint Services in SharePoint Server 2013 SharePoint Server 2013 Business Connectivity Services functionality Each of the six methods listed can be added to a dashboard page by using the relevant Web Part for the reporting function. For example, in order to put an Excel Report on a dashboard page, you would add an Excel Web Access Web Part to the dashboard page and link the Web Part to the specific Excel.xlsx file to show in the Web Part. Dashboard pages have built in page filters which can be linked to Report Web Parts to filter the contents by user or other information. Reporting Web Parts can also be linked to one another so that when you select a value in one report, the other connected reports are filtered by the current selection. Security and access for the Business Intelligence Center in Project Web App The Business Intelligence Center is a subsite of the Project Web App site and inherits permissions from the main Project Web App site. If you have users in your organization who require access to Project Web App reports, you can do one of the following:

71 You can break the permission inheritance between the Business Intelligence Center and the main Project Web App site. This allows you to add users to the Business Intelligence Center without giving them access to the Project Web App site. However, you will need to manually manage users who require access to both sites. You can create a site in the same site collection as Project Web App, but with different permissions, and deploy one or more dashboard pages to that site to make the needed reports available. The following SharePoint Server 2013 site permission levels are available: SharePoint Server 2013 site permission levels GROUP PERMISSION LEVEL ACCESS TO ODATA FEED Administrators for Project Web App Full Control Yes Portfolio Managers for Project Web App Design Yes Portfolio Viewers for Project Web App Design Yes Project Managers for Project Web App Read No Resource Managers for Project Web App Read No Team Leads for Project Web App No access No Team Members for Project Web App No access No These roles give the user access permissions to a set of items within the site. These items can be Reports, Report Templates, and Office Data Connections. For items that are Office Data Connections, the Secure Store Service credentials that are used for a given ODC provide access to data within the Project Web App and OLAP databases. If you must secure access to specific items within the site, such as restricting access to report folders, specific reports or Office Data Connections, you can customize security permissions on an exception basis by either creating a specific security group that helps secure these items or by editing the security permissions for each item. All of this is accomplished by using SharePoint Server 2013 security. We recommend that you do not rename or delete the default sample reports or template, or their containing folders. When patches and service packs are released in the future, these reports and templates may be recreated. Office Data Connections Office Data Connections are external files that can be used by multiple Excel reports. These files contain: 1. The connection information that is needed to connect and access the correct target database or OData feed. 2. The security credentials or authentication information needed to read data from the target data source. 3. The specific description of what data will be retrieved from the target database. This can include a SQL select query. Access to these files can be secured by using SharePoint Server 2013 security. You can also secure access to reporting data by creating separate Secure Store target applications for each account. Reporting in Project Online In Project Online, Project Web App data for reporting is only available through the OData feed. The OData feed

72 must be accessed through Excel OData reports can be published to the Business Intelligence Center and displayed using Excel Services, but the data cannot be refreshed using Excel Services. See also Overview of Excel Services in SharePoint Server 2013

73 Plan for performance and capacity in Project Server /13/ min to read Edit Online Summary: Read articles about how to plan for performance and capacity in Project Server Applies to: Project Server 2013 This section covers capacity planning for Project Server 2013 Articles about planning for performance and capacity for Project Server 2013 deployments The following articles about planning for performance and capacity for Project Server 2013 deployments are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 How datasets affect performance and capacity in Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Project Server 2013 Performance Lab (white paper) DESCRIPTION This chapter is about how to determine the hardware requirements for a single Project Server 2013 farm. Performance and capacity planning strategy is a vital part of planning a Project Server 2013 deployment. As you plan performance and capacity of a Project Server 2013 deployment, consider the set of variables that affect your plans. Read information and recommendations for how to scale-up or scale-out a Project Server 2013 farm. Contains information and recommendations for tuning a Project Server 2013 farm for optimized performance. Discusses Project Server performance counter information for web servers, database servers, and the Project application server. Project Server troubleshooting information for common bottlenecks and their causes on Project Server Learn about Project Server 2013 performance using various common workloads in a lab environment.

74 Overview of performance and capacity planning in Project Server /13/ min to read Edit Online Summary: Performance and capacity planning concepts are a vital part of planning a Project Server deployment. Applies to: Project Server 2013 This document and related content contain information and recommendations for how to determine the hardware requirements for a Project Server 2013 farm. This article identifies the characteristics that affect your capacity requirements, and it provides recommendations for the following: Number of server computers in the server farm Configuration of application server roles in the server farm Hardware requirements for specific server roles in the server farm Planning for capacity vs. availability in Project Server 2013 deployments This chapter assumes that you have already planned for availability requirements by using the IT Pro Planning for Project Server 2016 articles. As a result of using those articles, you will start the capacity planning exercise with a topology that meets your organization's minimum availability requirements. Given the topology you have selected, this chapter helps you determine the following: Whether you have to add more servers to meet your goals for capacity and performance Whether you have to adjust the configuration of application server roles to optimize capacity and performance of the server farm Whether you have to plan for more than one server farm based on your capacity requirements In some cases, an organization's requirements for availability can result in a server farm size that provides much larger capacity or performance than is otherwise required. If this is the case, capacity planning can focus on sizing the server hardware economically, instead of adding additional server computers or scaling up with higherperforming hardware. In many cases, the topology that meets an organization's minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals. Capacity planning approach for Project Server 2013 There are many variables that affect capacity planning. For this reason, it can be difficult to receive a crisp answer to a straightforward question. Consequently, the most common answer to a capacity-related question is, "It depends." The capacity planning exercise provided in this documentation set is designed to reduce the number of variables in consideration so that straightforward answers can be provided based on common scenarios. However, this chapter also includes the guidance for calculating your capacity and performance requirements based on your individual solution characteristics. This chapter includes two kinds of capacity planning guidance:

75 Recommendations for estimating capacity requirements A series of articles is provided, based on targeted scenarios. Each article defines a typical usage profile and identifies the key characteristics that will affect capacity and performance for the scenario. Based on the profile and key characteristics, predefined data lets you estimate capacity requirements for your solution. Formulas and guidance for calculating specific capacity requirements Using this guidance, you can develop your own usage profile (or modify one of the scenario profiles) and calculate all of the variables that affect the capacity and performance of your solution. Capacity planning process for Project Server 2013 deployments Capacity planning focuses on three aspects of sizing your solution: Capacity boundaries of the software Each of the features that can be implemented and the objects that can be created have scale limitations. Planning for capacity boundaries ensures that your solution design fits within the scale recommendations of the software. Throughput targets Each kind of action that is performed by a server farm introduces a performance load on the server hardware. Primary actions include user operations, indexing of content, and operations tasks (such as backing up the databases). The use of specific features, such as Excel Calculation Services, although necessary for cube building, also adds a performance load. Developing throughput targets involves estimating or calculating the number of operations per second that a server farm must process in order to support the expected throughput load. Data capacity Data capacity includes the expected volume of content databases and the configuration database. Each server role also has unique data requirements based on the solution, such as disk space for content indexes or for cached content. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

76 Capacity planning strategy for Project Server /13/ min to read Edit Online Summary: Performance and capacity planning strategy is a vital part of planning a Project Server deployment. Applies to: Project Server 2013 This article and related articles contain information and recommendations for how to determine the hardware requirements for a Project Server farm. The performance and capacity planning strategies outlined provide guidance on the footprint that the usage of Project Server 2013 has on topologies running SharePoint Server Estimating throughput targets in Project Server Many factors can affect throughput. These factors include the number of users; the type, complexity, and frequency of user operations; the number of postbacks in an operation; and the performance of data connections. Each of these factors can have a major impact on farm throughput. You should carefully consider the factors discussed in this section when you plan your deployment. Project Server 2013 can be deployed and configured in a wide variety of ways. As a result, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy Project Server 2013 in a production environment. In many cases, the topology that meets an organization's minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals. When you undertake your capacity planning for Project Server 2013, you need to be aware of the variables that can affect the performance of a Project Server deployment. Because of the rich functionality set that Project Server provides, deployments that seem similar when described at a high level can differ substantially in their actual performance characteristics. It's not enough to characterize your demands by just the number of projects, or the number of users you will have in the system. Thinking about the performance of your Project Server deployment requires a more nuanced and holistic approach. For example, workloads, and subsequently your hardware needs, will differ in relation to the following variables: 1. Projects: 2. Users: Number of projects Typical project sizes in terms of tasks Number of project level custom fields Level of linking (dependencies) between tasks Concurrency of users. How many users will be hitting the system at the same time? What is the average load, what are the spikes in traffic? What security permissions do users have? This affects both the amount of data the server needs to present to the user at a given time, along with the complexity of the security checks the server has to do. Geographic distribution of users. When users are spread over large geographical areas there can be detrimental performance effects due to network latency. This also impacts usage patterns insofar as

77 users are likely to hit servers at different times during the day, making it harder to find low-traffic periods in which to run maintenance tasks such as backups, reporting, or Active Directory sync. 3. Usage patterns: Workload conditions. Which set of features are being commonly utilized? For example, a deployment that uses time-sheeting heavily will have different characteristics than one that does not use time-sheeting.number of projects Average time between page requests. Average session time. Payload of Pages (How many Web Parts do you have on a given page? How much data do they contain?) To help you in your capacity planning, we define three data sets, which we have found to characterize small, medium, and large Project Server deployments. For each of these data sets, we then recommend one of three "rule-of-thumb" hardware topologies that should approximately satisfy the needs of similar datasets. With these starting point topologies in mind, we highlight factors that may require you to adjust these hardware topologies, outlining how you should evaluate if you need to decrease or increase the allocated resources to scale to your particular needs. The approach you should take in your capacity planning is as follows: 1. Determine which of the datasets (small, medium, or large), is the closest match to your expected dataset. This is covered in How datasets affect performance and capacity in Project Server Use the hardware topology we recommend for that dataset size as a starting point approximation for what your needs will be. Note It is important to realize that the needs of your particular dataset and usage patterns may require either fewer or more hardware resources than that approximate topology. Performance and capacity hardware recommendations for Project Server 2013 goes into depth about how you can assess whether you should add more resources to the topology, and where to add them. 3. Monitor your application's performance by using the guidelines we outline in the Performance counters in Project Server 2013 topic. In those topics we specify the key metrics you will want to track to determine when and how you need to scale your topology. 4. Optimize your deployment according to the suggestions provided in Optimize performance in Project Server Depending on your chosen topology, your dataset, your usage patterns, and the performance metrics you observe, follow the recommendations on scaling given in the following articles: Scaled-up and scaled-out topologies in Project Server 2013 : This article gives advice regarding the type of strategy you should pursue when scaling depending on your current needs. Should you purchase additional servers, or should you purchase additional resource capacity (memory, CPU, disk) for the servers you already have? Common Project Server 2013 Bottlenecks and their Causes: This section in the Performance troubleshooting in Project Server 2013 topic describes the likely source of bottlenecks in your system, how you might spot them through monitoring, and how issues related to these bottlenecks can commonly be resolved.

78 See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

79 How datasets affect performance and capacity in Project Server /13/ min to read Edit Online Summary: As you plan performance and capacity of a Project Server 2013 deployment, consider the set of variables that affect your plans. Applies to: Project Server 2013 Typical datasets in Project Server 2013 The datasets described in this article are characterized by the variables listed and explained in the table below. These variables may not capture all of the factors that affect the performance of Project Server. (That is, they do not capture the mix of features you tend to use in your deployment.) However, they do capture much of the information that is significant in determining appropriate capacity. Factors that affect performance in Project Server 2013 ENTITY DESCRIPTION/NOTES SMALL MEDIUM LARGE Projects Project Sites % Projects in Managed Mode 0% 10% 80% Tasks Average Tasks Per Project Task Transaction History The number of times status tends to be submitted and approved for any given task Assignments Average Assignments Per Task Average Tasks per My Site User Approvals Pending updates per manager Resources

80 ENTITY DESCRIPTION/NOTES SMALL MEDIUM LARGE Average Resources Per Project Average Assignments Per Resource Users Calendars Issues Risks Deliverables Enterprise Project Types 5 50 Workflows 2 30 Average Projects Per Workflow Phases 5 50 Phases Per Enterprise Project Type Stages Stages Per Workflow PDPs Custom Fields Per PDP Number of Departments Average Projects Per Department Average Resources Per Department Timesheets Per Year The more you utilize timesheets, the more resource demands will be placed on SQL Server

81 ENTITY DESCRIPTION/NOTES SMALL MEDIUM LARGE Status Reports Per Year Note In our dataset size descriptions, the number of custom fields includes only the enterprise custom fields, not department custom fields. Department custom fields have essentially the same effect on the performance of Project Server 2013 as enterprise custom fields do. Therefore, if you have a large number of departmental custom fields (especially at the task level) you will require additional resources to support this. The prescriptions that are made regarding custom fields throughout this document apply to both enterprise custom fields and department custom fields. Other performance and capacity variables to consider in Project Server 2013 Concurrency of users: Concurrent user load is often a significant factor in setting capacity requirements. You may have fewer users in the system, but they may all transact with the server simultaneously during your "peak" traffic periods. For example, an organization that has its users all submit status/timesheet updates at the same time of the week will likely notice a substantial decrease in performance during those periods. If you have heavy peak usage periods, you should add more resources to the topology recommended for your dataset. Split of user roles: The distribution of your users between Administrators, Portfolio Administrators, Project Managers, and Team Members will affect the performance of your deployment insofar as each type of user has access to a varying amount of data. Users in different security categories may vary with regard to how many projects and resources they may be able to see. Administrators, for example, will be able to see all projects on the server when loading Project Center, and all resources when they load Resource Center. In comparison, a Project Manager may be able to see only his or her own projects. The result is that these users may be subject to a diminished perceived performance. Where possible, we suggest you limit the number of projects, tasks, or resources shown in a given view by defining appropriate filters in the views that you define in the >Manage Views section of Server Settings. Issues, risks, and deliverables: Having larger numbers of these entities may place additional load on SQL Server. In particular, it is the act of viewing and interacting with these entities in the project site that is likely to create the additional load. If you use these features heavily, you may want to allocate additional resources to SQL Server to maintain a high level of performance. These artifacts and the project site functionality are SharePoint sites and lists, so for scaling these aspects of Project Server 2013, consult documentation around scaling SharePoint sites and lists. Custom Calendars: Custom calendars can be defined for projects, tasks and resources. These largely impact the scheduling engine, causing higher processor usage on the Application and Database servers. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013

82 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

83 Performance and capacity hardware recommendations for Project Server /13/ min to read Edit Online Summary: Use these hardware recommendations regarding performance and capacity for Project Server 2013 to identify a suitable starting topology for your requirements. Applies to: Project Server 2013 They will also help you decide whether you have to scale out or scale up the starting topology. Throughout this set of articles we refer to three different server roles: the Web Front End Server role, Application Server role, and Database (SQL) Server role. These are all components of a complete Project Server 2013 deployment. The front-end Web servers act as the interface for users accessing Project Server. The Application server handles the requests to the data tier of Project Server, and implements the business logic of Project Server Lastly, the database tier is the data source, housing the Project Server 2013 database. For small deployments, the Web Front End Server, Application Server, and Database Server roles may be combined on the same physical computer. For larger deployments it may be necessary to separate these onto separate computers, even having multiple physical computers acting in the same role. Hardware requirements and recommendations for Project Server 2013 This section suggests a minimum requirement and a recommended topology for each of the small, medium, and large dataset sizes characterized in How datasets affect performance and capacity in Project Server The minimum requirement is a topology that will be functional with the given data set, but may suffer from substantially decreased perceived performance. The recommended topologies for each dataset should be sufficient for obtaining reasonable performance with most usage patterns on those dataset sizes. However, we encourage you to take into account the specific recommendations given throughout the rest of this document for determining if you will need to expand beyond the topology that is recommended for your approximate dataset. In general, you should monitor the performance metrics of your topology, and scale it accordingly if you are unsatisfied with the performance characteristics. Small dataset hardware recommendations for Project Server 2013 Medium dataset hardware recommendations for Project Server 2013 Large dataset hardware recommendations for Project Server 2013 Virtualization recommendations for Project Server 2013 Project Server 2013 supports running on virtual machines. Most of the advice given for virtualization of SharePoint Server 2013 also applies to Project Server However, as in any situation where virtualization is employed, it is important to consider contention for the physical machine's resources between virtualized machines running on the same physical instance. We do not recommend running SQL Server on a virtualized machine. The competition for resources on a virtualized machine can substantially decrease the performance of SQL Server. If you must run SQL Server in a virtual environment, we recommend that you use the following settings: Network Adapter: If you are using Hyper-V virtualization, you should utilize the virtual network adapter rather than the legacy network adapter.

84 Virtual Disk: For the virtual machine that you are running SQL Server on, we recommend that you select the "pass through" option for the disk type (rather than dynamic, or fixed). If this is not an option, you should utilize a fixed disk size rather than a dynamically sized virtual disk. We recommend that you select IDE over SCSI for your boot drive. Allocate sufficient hard disk space to handle the expected maximum size of your dataset and ULS logging demands. Memory: You should allocate as much memory to the virtual machine that is running SQL Server as can feasibly be allocated. This should be comparable to the amount of memory required/recommended for physical boxes serving the same function. You need to also account that some memory needs to be reserved for the host operating system. At least 2 GB of memory should be reserved for the host operating system. Running the Web Front End or Application Servers in virtualized environments tends to not be as detrimental to the performance of running SQL Server in a virtual environment. Network requirements for Project Server 2013 deployments For most Project Server deployments, network bandwidth tends to not be the bottleneck on performance. The table below lists the recommended specifications of network components. COMPONENT SMALL AND MEDIUM LARGE # of NICs 1 2 # NIC Speed (Network) Any speed greater than 100mbps should be fine 1 Gb/s Load Balancer Type NLB or hardware, both are acceptable NLB or hardware, both are acceptable A general aim should be to maintain low latency between the Application and SQL Server tiers. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

85 Small dataset hardware recommendations for Project Server /13/ min to read Edit Online Summary Here are the hardware recommendations for a small deployment of Project Server Applies to: Project Server 2013 Minimum requirements for hardware for Project Server 2013 A single server that acts in all three roles: Application Server, Web Front End, and Database (SQL) Server. This server contains the SharePoint Content database and the four Project Server databases. Minimum requirements for hardware components for Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single-server and multiple-server farm installation for production use 80 GB for installation For production use, you need additional free disk space for day-to-day operations. Add twice as much free space as you have RAM for production environments. Recommendations based on coexistence with SharePoint Server 2013 Because Project Server 2013 coexists with SharePoint Server 2013, it generates additional resource usage (processor, RAM, and hard disk). The guideline requirements for SharePoint Server 2013 are also valid for a Project Server 2013 installation with a small data set and light usage. However, for more substantial data sets and usage patterns, additional hardware resources will be required. For a single-box deployment, with a small data set, we advise 16 GB of RAM to assure a high level of perceived performance. Beyond this, if possible, we recommend that you separate your SQL Server from the Application and front-end Web tiers by placing your databases onto a dedicated computer that is running SQL Server. Web Front End and Application Server recommendations for Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single-server and multiple-server farm installation for production use 80 GB SQL Server database recommendations for Project Server 2013

86 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core(if your dataset size is considerably larger than the medium dataset, 8 cores are recommended) 16 GB 8 GB for single-server and multiple-server farm installation for production use 80 GB See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

87 Medium dataset hardware recommendations for Project Server /13/ min to read Edit Online Summary: Learn the system requirements such as RAM, disk space, processor speed for server hardware for Project Server Applies to: Project Server 2013 Minimum requirements for hardware for Project Server 2013 For a medium dataset, we suggest that as a minimum you have a dedicated Web server, Application server and computer that is running SQL Server. This is what is referred to as a topology. The recommended hardware specifications for each of the servers are stated following the diagram. Scaled-up and scaled-out topologies in Project Server 2013 gives more instructions on how to achieve this separation of the tiers across multiple servers. Minimum requirements for a front-end Web server COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single server and multiple server farm installation for production use 80 GB Minimum requirements for an Application server COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core 8 GB for developer or evaluation use 16 GB for single server and multiple server farm installation for production use 80 GB Minimum requirements for a computer running SQL Server COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core(if your dataset size is considerably larger than the medium dataset, 8 cores are recommended) 16 GB 100 GB

88 In some cases people use the SharePoint Server 2013 instance that Project Server is installed on top of as their primary SharePoint Server deployment. For small databases this may be a feasible approach, but we recommend against it for medium and large databases. If the SharePoint Server 2013 instance that Project Server 2013 is coexisting with also gets heavy usage (that is, you are not using it specifically for Project Server 2013 functionality), then you can separate the Project Server 2013 ProjectService database from the SharePoint Server 2013 content databases. You can do this by placing the Project Server 2013 ProjectService database on its own dedicated instance of SQL Server. Recommended hardware for Project Server 2013 The minimum requirements specified for medium sets can be scaled-out and scaled-up to handle additional load. Scaled-up and scaled-out topologies in Project Server 2013 discusses considerations about how to handle increased user load and increased data load. If your dataset is substantially larger than the medium dataset or you heavily use some of the features that generate additional data load, such as timesheets, then we advise you to take some of the measures described inscaled-up and scaled-out topologies in Project Server 2013 to handle your additional user and data load. As a general prescription, you should prepare for additional user load and data load by having sufficient computers to add additional front-end Web servers and Application servers to your topology. The hardware specifications of your front-end Web servers and Application servers can remain largely the same. A 4 x 2 x 1 topology should be sufficient for handling the needs of most medium datasets and usage patterns. Note that scaling out your Application and front-end Web servers adds more load to SQL Server, which you will have to compensate for by adding more memory and CPU resources. The following SQL Server specification should be able to handle the performance needs of most medium datasets. SQL Server database recommendations for Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, eight-core, 2.5 GHz minimum per core (If your dataset size is considerably larger than the medium dataset, 8 cores are recommended.) 32 GB 160 GB > [!NOTE]> Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. > [!NOTE]> RAID 5 should provide a good compromise between reliability, and throughput See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013

89 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

90 Large dataset hardware recommendations for Project Server /13/ min to read Edit Online Summary Here are the hardware recommendations for a large deployment of Project Server Applies to: Project Server 2013 For large datasets, the data load will be the most substantial performance bottleneck. Generally, at a minimum for large datasets you will want a topology. The hardware characteristics of the front-end Web and Application servers can generally remain the same as those recommended for the small and medium datasets. However, given that the SQL Server tier will be the bottleneck, you may find that this constrains your ability to scale out to additional front-end Web and Application servers. If data load is your bottleneck, you may find that additional front-end Web and Application servers do not produce an improvement in throughput. For large datasets, it is possible that the SharePoint Server 2013 instance that Project Server 2013 is coexisting with is also getting heavy usage (that is, you are not using that SharePoint Server 2013 deployment specifically for Project Server 2013 functionality). In this case we recommend that you separate the Project Server 2013 ProjectService database from the SharePoint Server 2013 content databases, placing it on its own dedicated computer that is running SQL Server. Given that the SQL Server tier will be your bottleneck, you will want to invest in additional resources on the SQL Server tier of your topology. You can "scale-up" your SQL Server by adding additional RAM, CPU, and hard disk resources. The tables that follow give the minimum and recommended specifications for the SQL Server tier of a large dataset topology. Minimum requirements for hardware for Project Server 2013 SQL Server database minimum requirements for Project Server 2013 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, four-core, 2.5 GHz minimum per core If your dataset size is considerably larger than the medium dataset, 8 cores are recommended. 32 GB 250 GB NOTE - Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. NOTE - RAID 5 should provide a good compromise between reliability, and throughput. Recommended hardware for Project Server 2013 SQL Server database recommendations for Project Server 2013

91 COMPONENT Processor RAM Hard disk MINIMUM REQUIREMENT 64-bit, eight-core, 2.5 GHz minimum per coreif your dataset size is considerably larger than the medium dataset, 8 cores are recommended. 64 GB 300 GB or more NOTE - Ideally, you should separate and prioritize data among disks. Place your data files and your SQL Server transaction logs on separate physical hard disks. NOTE - RAID 5 should provide a good compromise between reliability and throughput. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

92 Scaled-up and scaled-out topologies in Project Server /13/ min to read Edit Online Summary: Learn how to increase the capacity of existing servers or add more servers to the topology of your Project Server 2013 installation. Applies to: Project Server 2013 This article covers performance and capacity planning scaled-up and scaled-out topologies for a Project Server deployment. This document and related content contains information and recommendations for how to scaleup or scale-out a Project Server 2013 farm. Scaled-up and scaled-out topologies for Project Server 2013 deployments To increase the capacity and performance of your topology you can do two things. You can scale up by increasing the capacity of your existing server computers and scale out by adding additional servers to the topology. Monitoring resource usage on your Project Server 2013 deployment servers can give insights into which strategy you will want to pursue: scaling-up versus scaling-out. The performance metrics that can help inform your decisions are discussed in Performance counters in Project Server The physical servers that you deploy Project Server 2013 on will play the following server roles: Web Front End Application Server Database (SQL) Server In a single-machine deployment, one physical server plays all three of these roles. You can scale out by dividing ownership of these roles amongst different physical machines (optionally, they could also be virtual machines. Read the "Virtualization" section of Performance and capacity hardware recommendations for Project Server 2013 for additional guidelines about virtualization). The first step you should take when starting to scale out is to separate the Database (SQL) Server role onto its physical machine, while having the other physical machine act as the Web Front End and Application Server. Note Project Server 2013 only provides limited scale-out capabilities. While additional servers can be added to act as front-end web servers and Application servers, on the back end the computer that is running SQL Server has limited scale-out possibilities. To provide for more user load Scale-out by adding more web servers to serve as dedicated Application and front-end web servers. Note that as you add more front-end web servers and Application servers, the load on computer that is running SQL Server will increase, and your SQL Server could in turn become your bottleneck. You may also scale up any front-end web or Application server to improve performance by increasing

93 the hardware capacity of those servers. To provide for more data load To provide for more data load, add capacity to the database server by increasing the capacity of that single server. Separate the Project Database from the SharePoint Databases by moving the Project database onto its own dedicated database server. Note Project Server 2013 does not support scaling out the Database component through SQL replication. While it is possible to perform SQL mirroring on a Project SQL Server for the purposes of backing up data, Project Server 2013 is unable to take advantage of SQL replication to reduce read loads on the SQL Server. Recommended server role ratio: As a general rule, a recommended ratio for maintaining a manageable load on the SQL Server is: 2 Web Front Ends : 1 Application Server : 1 SQL Server Note This recommended ratio might not apply for deployments utilizing more robust hardware, especially for the database server. Note The recommended ratio also varies based on the data set size, and the usage patterns. For example, larger data sets would constrain the ability to fan-out, requiring a smaller ratio of Web Front Ends and Application Server to the SQL Server. Isolate the Project Server database from SharePoint Server: As previously mentioned, it is possible to separate the Project Server database from the SharePoint databases, by placing it on its own dedicated database server. We also recommend that you separate at the application tier level. While Project Server is a SharePoint service, we recommend that you have that application instance run on a dedicated server. How to spend money on scaling up and out: As a general rule, in the early stages of scaling your Project Server deployment, you will want to invest primarily in purchasing additional memory. Most often, the subsequent areas you would want to invest in are disk spindles, and then network resources. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013

94 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

95 Optimize performance in Project Server /13/ min to read Edit Online Summary: Read guidelines for optimizing performance for a Project Server 2013 deployment. Applies to: Project Server 2013 Optimizations This document and related content contains information and recommendations for tuning a Project Server 2013 farm for optimized performance. Baselining Generally, we recommend that you limit the number of baselines that you have saved at any given time. There is a hard limit of only 11 baselines supported at a given time. Database server optimizations Given that Project Server 2013 is a data intensive application, optimizing your database tier can add considerable gains to performance. Please refer to SQL Server Storage Capacity Planning and Configuration topics for broad guidelines on optimizing your SQL Server settings. Some of the recommendations here highlight those made in the SQL Server topics: Separate the database files and the transaction log files away from the OS drives preferably each to their own partition. This helps by reducing IO contention between the host operating system and SQL Server, and then also between SQL database files and log files, which tend to have different update patterns depending on what recovery strategy is used. Separate the TempDB onto its own partition. Split the database into several physical files ideally, splitting it into as many files as you have processors on your database server. Consider utilizing a RAID subsystem for your data needs. Note - RAID 5 is acceptable for medium and large dataset sizes, but RAID 10 is ideal. Note - Move indexes onto their own partition. Optimizing master projects When you use the Master Projects functionality in Project Server, note that changes in the Master Project schedule will have an impact on the schedules of subprojects within the Master Projects. Therefore, schedule changes for very large Master Projects may execute slowly, because their subproject plans may need to be updated. Security setting optimizations Note - Optimizations are unnecessary if you are using SharePoint Permission Mode. In Project Permissions Mode, the security settings you select for your users can have a significant effect on performance characteristics. This is because they determine both the amount of data that users load when they view projects, and also the complexity of the security checks that are performed to determine which sets of data users have permissions on. For example, Administrators will have access to all of the projects that you have stored in Project Server, and they are therefore required to load all of the data when interacting with them. Team members may not need access to all the data, so we can limit the amount of data that is sent to them by using security categories: Use groups and categories where possible rather than more granular permissions that require additional

96 complexity in the security checks. Try to restrain users' security permissions to the projects they need to have access to. That way, they load only the data they need to when interacting with Project Server. Views optimizations One should attempt to limit the data that is presented to users by restricting the number of columns in a given view to only the columns that users with permission on that view need to see. Also, note that adding Custom Field columns will have a more detrimental effect on view performance. You may also use filters to limit the amount of data that must be loaded when you are loading a particular view. Be aware, however, that filters with complex logic require additional computation, and may as a result slow down performance. Custom field optimizations The performance impact of custom field usage depends on several aspects of the custom fields that are used (both Department and Enterprise custom fields). The following are some considerations and suggestions regarding the performance aspects of custom fields. The performance impact of your custom fields will depend on the following: The performance impact of your custom fields will depend on the following: The quantity of data stored in the custom fields you use. (Are they generally sparse, or are there large quantities of data in a given custom field column?) For formula fields, the more complex the formulas employed, the more substantial the negative impact on performance will be. The level the custom fields occur at: The quantity of data stored in the custom fields you use. (Are they generally sparse, or are there large quantities of data in a given custom field column?) For formula fields, the more complex the formulas employed, the more substantial the negative impact on performance will be. The level the custom fields occur at. There are usually far more tasks than projects in a dataset and, therefore, custom fields applied at the task level will have a more substantial negative impact on performance than project level custom fields. Generally, the prescription is to try to limit the number of custom fields used, especially at the task level. As a general rule, try to use less than task level Enterprise Custom Fields. Task and assignment custom fields are the primary bottleneck in saving from Project Professional to the server in most observed customer data sets. Local custom field optimizations In accord with the recommendations about optimizing custom field use, optimize local formula field use by limiting the number of local formula fields used in the Project client. The performance impact of your custom fields depends particularly on limiting the use of formula fields where possible, as they require additional data transfer that increase the time required for saving to the server. Page payload optimizations One of the most important factors in determining a given page's load time is the amount of data that needs to be accessed on a given page request. This is largely determined by the number of Web Parts and the types of Web Parts and how much data they present on a given page. The following are some general recommendations on limiting the payloads of your Project Server pages: Limit the amount of data that these Web Parts load to only the data that they need to be loading.

97 Payload considerations are particularly important for Project Detail Pages (PDPs), where there tend to be a larger number of Web Parts on a given page, and more customization occurs. Queue optimizations Project Server 2013 utilizes a queuing system to handle how it services requests, enabling it to serve a greater number of requests overall. Certain settings related to how the queue operates can be altered through the Queue Settings page. This section gives a brief explanation of the settings you can modify, and how to optimize them for your needs. Max Number of Threads (1-20, default 4): This determines how many jobs the queue can process in parallel at any given time. Note that this applies to all machines in the farm if you have three Application servers, and you set this value to 4 for the project queue, you can process up to 12 independent project jobs at a time. Max Number of Threads (1-20, default 4): This determines how many jobs the queue can process in parallel at any given time. Note that this applies to all machines in the farm if you have three Application servers, and you set this value to 4 for the project queue, you can process up to 12 independent project jobs at a time. If you find that queued jobs are taking an excessive amount of resources away from a synchronous workload, you can try the following: If you have a large number of jobs that are processed in parallel (that is, you see multiple jobs in the "processing" state at the same time when you check the queue status), you can try reducing the thread count. Workload process optimizations Certain aspects of how you operate and maintain your Project Sever deployment can help improve the perceived performance of Project Server. This section covers a list of Business- or IT-related process modifications that can help to improve the perceived performance of your Project Server during periods when your users are most likely to interact with the system. Timesheeting and status submissions: If possible, try to stagger the times when users submit status updates and timesheets. This will act to reduce the strain on the system during peak periods by distributing the load over larger time intervals. Backups: If possible, you should try to run backup processes during non-peak periods, as these are resource intensive processes that will diminish perceived performance for users attempting to use the system while they are running. Reporting: As with backup processes, you should try to run the building of OLAP cubes for reporting during nonpeak periods, as these are resource intensive processes that will diminish perceived performance for users attempting to use the system while they are running. SharePoint Permissions mode: If SharePoint Permissions mode is enabled "SharePoint User Sync" is not required thus allowing better performance. Workflow optimizations When you are using the Workflows functionality, be aware of the following actions that will take a toll on the performance of your deployment: It can take a long time to load the "Change or Restart Workflows" page in Server Settings when you have a large number of projects stored in the database. Restarting or changing the EPT for a large number of projects from Change or Restart Workflows page in Server Settings. Having an approval process with a very large number of users. Having projects submitted at the same time from a workflow stage without check-in required.

98 Generally, we recommend minimizing these actions, or executing them at low-traffic periods to optimize perceived performance. Custom solution (programmability) optimizations When you develop custom solutions that interact with the Project Server Programmable Interfaces, take into account the following performance recommendations: If you are deploying event handlers, be aware that the event handlers are synchronous. You should be careful when employing event handlers in your custom solutions, as if utilized ineffectively they can substantially increase the performance of Project Server. > [!NOTE] > Event handlers can be run off on another machine. Your custom solution should try to throttle calls it makes to queuing operations in the Project Server to prevent overloading the queue. For Line of Business (LOB) Applications, when you automate data movement between Project Server and other applications, if you notice that syncs with these types of applications are substantially degrading performance, it is advised to run them during non-peak usage periods. We highly recommend that customers test and monitor their LOB application performance, in addition to their user-facing performance. Where possible, try to utilize intrinsic Project Server fields rather than custom fields to achieve the sync that you desire between Project Server and the LOB applications. Try to minimize the data you are moving between LOB applications and Project Server to the smallest subset you need for achieving the desired functionality. The Project Server 2013 SDK and related articles make further recommendations about maintaining high performance when developing custom solutions. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

99 Performance counters in Project Server /19/ min to read Edit Online Summary: Use performance counters to monitor the health of a Project Server 2013 farm. Applies to: Project Server 2013 To help you determine when you have to scale up or scale out your Project Server 2013 farm, use performance counters cited in this article to monitor the health of the system. The information in the following tables can be used to determine which performance counters to monitor, and to which process the performance counters should be applied: Web servers Database servers Project Application Server performance counters The following table shows performance counters and processes to monitor for Web servers in your Project Server 2013 farm. Performance counters and processes to monitor for Web servers PERFORMANCE COUNTER APPLY TO OBJECT NOTES Processor Time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions. Memory Utilization Application Pool Shows the average utilization of system memory for the application pool. You must specify the correct application pool to monitor. The basic guideline is to determine peak memory utilization for a given Web application, and assign that number plus 10 MB to the associated application pool. The following table shows performance counters and processes to monitor for database servers in your farm. Performance counters and processes to monitor for database servers PERFORMANCE COUNTER APPLY TO OBJECT NOTES Average disk queue length Hard disk that contains SharedServices.mdf Average values larger than 1.5 per spindle indicate that the write times for that hard disk are insufficient. Processor time SQL Server process Average values larger than 80 percent indicate that processor capacity on the database server is insufficient.

100 PERFORMANCE COUNTER APPLY TO OBJECT NOTES Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions. Memory utilization Total Shows the average utilization of system memory. The following table shows performance counters and processes to monitor for your Application server. Performance counters and processes to monitor for your Application server PERFORMANCE COUNTER APPLY TO OBJECT % Sql Retries / Day ProjectServer:QueueGeneral Active Job Processing Threads Active Job Processing Threads Average Unprocessed Jobs / Day Current Unprocessed Jobs New Jobs / Minute Sql Calls / Hour/Day Sql Calls / Minute Sql Retries / Minute ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral ProjectServer:QueueGeneral % Jobs Failed / Day ProjectServer:QueueJobs % Jobs Failed / Hour ProjectServer:QueueJobs % Jobs Retried / Day ProjectServer:QueueJobs % Jobs Retried / Hour ProjectServer:QueueJobs Average Processing Time / Day Average Processing Time / Minute Average Wait Time / Day Average Wait Time / Minute Jobs Failed / Minute Jobs Processed / Hour/Day ProjectServer:QueueJobs ProjectServer:QueueJobs ProjectServer:QueueJobs ProjectServer:QueueJobs ProjectServer:QueueJobs ProjectServer:QueueJobs

101 PERFORMANCE COUNTER Jobs Processed / Minute Jobs Retried / Minute Average time taken for Project Open Percentage of incremental save to full save Winproj full open count in the last hour Winproj full save count in the last hour Winproj incremental open count in the last hour Winproj incremental save count in the last hour APPLY TO OBJECT ProjectServer:QueueJobs ProjectServer:QueueJobs ProjectServer:Winproj ProjectServer:Winproj ProjectServer:Winproj ProjectServer:Winproj ProjectServer:Winproj ProjectServer:Winproj See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

102 Performance troubleshooting in Project Server /13/ min to read Edit Online Summary: Read troubleshooting information for common bottlenecks and their causes in Project Server Applies to: Project Server 2013 During performance testing, several different common bottlenecks can be revealed. A bottleneck is a condition in which the capacity of a particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput. By monitoring your performance using the guidelines specified in the Performance Monitoring section, you may be able to better identify which bottlenecks are impacting the perceived performance of your Project Server deployment. Common bottlenecks, causes, and resolutions The following table lists some common bottlenecks and describes their causes and possible resolutions: BOTTLENECK CAUSE RESOLUTION Database contention (locks) Database server disk I/O Front-end web CPU utilization Database locks prevent multiple users from making conflicting modifications to a set of data. When a set of data is locked by a user or process, no other user or process can modify that same set of data until the first user or process finishes modifying the data and relinquishes the lock. When the number of I/O requests to a hard disk exceeds the disk's I/O capacity, the requests will be queued. As a result, the time to complete each request increases. When a WFE is overloaded with user requests, average CPU utilization will approach 100 percent. This prevents the WFE from responding to requests quickly and can cause timeouts and error messages on client computers. To help reduce the incidence of database lock contention you can: Scale up the database server. Tune the database server hard disk for read/write. Distributing data files across multiple physical drives allows for parallel I/O. Limit the number of projects and fields shown in a given view, so that limit the amount of data requested from the Database server. Try to limit the number of custom fields you utilize, especially at the task level. Formula fields at the task level are particularly costly in terms of database server disk I/O when performing save operations from Project Professional. This issue can be resolved in one of two ways. You can add additional WFE servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higherspeed processors.

103 BOTTLENECK CAUSE RESOLUTION Server Memory Utilization Active Directory Sync Application Server CPU Database Server CPU When you have a substantial number of large queue jobs executing, the server memory utilization can spike. More complex server side scheduling calculations, or evaluation of formula custom fields, can also consume substantial memory resources. As a result, the time to complete each request increases. Project Server users and resources can be synchronized with the users of the service across multiple domains and forests. This feature helps administrators with tedious tasks, such as manually adding large numbers of users, updating user metadata such as addresses, and deactivating users who no longer require system access. Active Directory synchronization can be done manually or on an automated schedule. The process of synchronization is resource intensive Application Server CPU can be hit hard when: Scheduling complex projects. Evaluating formulas on complex projects/ Running portfolio analyses on a large number of projects with Time-phased Resource Planning analysis turned on. Usually, database server CPU spikes when try to load views that comprise of a large number of projects, and a large number of fields shown. This will reduce the perceived user response time when that view is applied. Monitor at which tier memory usage is a bottleneck:that is, is the memory scarcity happening on the Application server, the front-end web server, or the database server. To resolve the lack of memory there are two options: Purchase and install additional memory for that tier. Purchase additional application servers to handle the load. It is best to run Active Directory Sync during non-peak user usage periods. That way, Active Directory Sync will not degrade the perceived performance of users. In addition, try to avoid heavily nested groups, as they increase the complexity of the sync that must be performed, and result in longer sync processes. Monitor the Application Server's CPU usage, and if it seems that it is utilizing a high percentage of its CPU resources, then add an additional Application Server to your topology to distribute the load. Note that adding an additional Application Server will add additional threads that could cause increased load on the Database Server. This could create a new bottleneck on the database server, which may be resolved by allowing fewer Job Processor Threads in the Queue Settings. Limit the number of projects and the number of fields shown in a given view. See also Overview of performance and capacity planning in Project Server 2013 Capacity planning strategy for Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Scaled-up and scaled-out topologies in Project Server 2013

104 Optimize performance in Project Server 2013 Performance counters in Project Server 2013 Performance troubleshooting in Project Server 2013 Typical Datasets (Project Server 2013)

105 Project Server 2013 Performance Lab (white paper) 12/13/ min to read Edit Online Applies to: Project Server 2013 Learn about Project Server 2013 performance using various common workloads in a lab environment. This performance lab white paper created by the Microsoft Project Server engineering team explores the behavior of a "large" synthetic dataset in response to several common workloads in Project Server You can use this information to provide a rough baseline for Project Server 2013 performance in this defined lab environment. It is important to note that your actual performance may differ due to numerous variables in your own environment. To download this white paper, click the following link: Project Server 2013 Performance Lab See also Plan for performance and capacity in Project Server 2013 Performance and capacity hardware recommendations for Project Server 2013 Overview of performance and capacity planning in Project Server 2013 Performance counters in Project Server 2013

106 Plan EPM Solution architecture in Project Server /13/ min to read Edit Online Summary: Plan for the client, application, and database tiers in a Project Server solution. Applies to: Project Server 2013 This chapter describes the components of a Project Server 2013 deployment. This material is written for executives, managers, and system administrators who are responsible for planning the deployment of Project Server. Project Server 2013 is deployed across multiple tiers: a client tier, a Web tier, an application tier, and a database tier. Applications and services in each tier provide for availability and scalability, which enables any size organizations to manage projects of a range of sizes and levels of complexity. You can configure the application and database tiers of Project Server to best meet the needs and requirements of your organization. Project Server 2013 is deployed on an existing SharePoint Server 2013 farm. It is important that you include planning for SharePoint Server 2013 as part of your Project Server deployment plans. For more information, see Planning and architecture for SharePoint Server Understanding Project Server architecture In this chalk talk, Microsoft Program Manager Chris Boyd discusses Project Server architecture, including the differences between Project Server 2010 and Project Server Video: Project Server architecture TechNet articles about planning EPM solution architecture in Project Server 2013 The following articles about are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Plan the client tier in Project Server 2013 Plan the application tier in Project Server 2013 Plan the database tier in Project Server 2013

107 Plan the client tier in Project Server /13/ min to read Edit Online Summary: Plan for Project Professional, task synchronization, and browser support in Project Server Applies to: Project Server 2013 This article identifies the key components of the client tier in a Project Server 2013 deployment. The client tier includes Microsoft-based applications and any custom applications that are specific to your organization. Project Professional 2013 in a Project Server 2013 deployment Project Professional 2013 is a desktop application that enables project managers to create, publish, and manage projects. In addition to scheduling and tracking tools, Project Professional 2013 provides project managers with enterprise resource and portfolio management capabilities. For information about deploying Project Professional 2013 in an enterprise environment, see Office 2013 Resource Kit. Outlook in a Project Server 2013 deployment SharePoint Server 2013 integrates with Exchange Server 2013 to provide task synchronization between SharePoint Server and a user's Exchange Server account. Project Server can use this functionality to synchronize a user's Project Server tasks and make them available in Outlook or on devices that allow the user to connect to their Exchange Server account. Users can also receive reminder notifications for tasks that they are assigned in projects that are stored in the Project Web App database. Browser support in Project Server 2013 Project Server 2013 and Project Web App support the same browsers as SharePoint Server For information about which browsers are supported, see Plan browser support (SharePoint 2013) Third-party and line of business applications in a Project Server 2013 deployment Many organizations use line-of-business client applications or develop business-specific applications. These applications call Project Server 2013 by using the Project Server Interface an extensible set of Web services and must also be integrated with a Microsoft Windows-based platform. Project Server 2013 provides a complete Software Development Kit (SDK). See also Volume activation of Office 2013

108 Plan the application tier in Project Server /13/ min to read Edit Online Summary: Learn what components of the application tier that you should plan for in a Project Server 2013 deployment. Applies to: Project Server 2013 The application tier in Project Server 2013 includes the following components: SharePoint Server 2013 Project Server 2013 Project Server Interface Project Server 2013 Events service Project Server 2013 Queue service Exchange Server Other applications (described in this article) SharePoint Server 2013 The Enterprise edition of SharePoint Server 2013 is required for Project Server SharePoint Server 2013 has many features in its own right, and deployment of SharePoint Server 2013 should be carefully planned. For information about how to plan your SharePoint Server 2013 deployment, see Planning and architecture for SharePoint Server Project Server 2013 Project Server 2013 is a robust and highly scalable Web-based server application that is integrated with several client applications, the Windows Server platform, and SQL Server 2008 R2 or SQL Server You can run the Project Server 2013 service on one or more application servers in a SharePoint Server 2013 farm. Project Server Interface The Project Server Interface is the application programming interface (API) of Project Server The Project Server Interface object model exposes Project Server 2013 functionality to all external applications. Project Professional 2013, Project Web App, and line-of-business and other third-party applications use the Project Server Interface (PSI) to access Project Server 2013 data that is stored in a Project Web App database. The PSI is available through Web service calls by back-end line-of-business applications, or through a Project Server Interface proxy for client applications having a user interface. Project Server 2013 Events service The system-level Project Server 2013 Events service manages the Project Server 2013 events. Other applications can subscribe to Project Server 2013 pre-events and post-events, and register event handler methods through Project Web App. Event handlers can check business rules and cancel an operation through a pre-event, or extend Project Server 2013 with additional processing such as workflow by using a post-event (for example, ProjectPublished).

109 Project Server 2013 Queue service The Save and Publish queue manages new and incremental saves of working projects and also manages publishing a project. Exchange Server Exchange Server 2013 integration with SharePoint Server 2013 allows for Project Web App users to view Project Server and SharePoint Server tasks in Microsoft Outlook and on devices that can access the user's Exchange Server account. Other applications Third-party and line-of-business applications can be used with Project Server By using the Project Server Interface, you can address many project management needs with these applications. The following are some sample scenarios: Project proposals Create placeholder projects during project initiation and use project custom fields to tag the project with information needed for the initiation and approval process. Add tasks to identify project phases for key milestones or deliverables. When approved, project proposals can evolve into full-scale projects that are managed by using Project Professional Maintenance projects Create placeholder projects to use with resource plans. Reserve or book time against resources for maintenance work or base business. Maintenance projects generally do not have tasks. Financial projects Create projects for time capture through the timesheet for integration with a financial system. Create tasks for a hierarchy of financial codes that reflect the cost breakdown structure of the financial system. These projects do not require scheduling or status updates. Integration with project accounting systems Capture the resource costs and expenses associated with projects to feed financial and billing systems and for budget comparison purposes. Synchronize tasks, resources, and assignments between the systems. Capture timesheet data in one system to feed the other (which timesheet is used depends on the needs of the organization or of individual projects). Integration with work or task management systems Synchronize tasks and assignments between Project Server 2013 and systems such as Microsoft Visual Studio Team System. Microsoft Visual Studio Team System is integrated with Project Standard 2013 and Project Professional 2013, but integration with Project Server 2013 requires developing components by using the PSI. Process updates from team members For projects that are not actively managed, automatically update them on the server by using information from team members about progress and other changes. Projects can be updated and republished without a project manager reviewing the results or making adjustments to the plan.

110 Plan the database tier in Project Server /13/ min to read Edit Online Summary: Learn how data is partitioned within a Project Web App database and which tables are available for use externally. Applies to: Project Server 2013 This article identifies the key components of the database tier. The data access layer is internal to Project Server 2013 and is not exposed to external applications. The data access layer translates between the logical business entity representation of the data and the physical database tables. Each logical entity is stored in a number of different tables. The data access layer encapsulates the work required to manage connections, execute queries, and begin, commit, and roll back transactions. Project Server 2013 data is contained in a single database for each instance of Project Web App, partitioned into four table schemas: The Draft tables contain unpublished projects from Project Professional Project data in these tables is not accessible by using Project Web App. The Published tables contain all of the published projects as well as tables that are specific to Project Web App (timesheets, models, views, and so on), and global data tables (outline codes, security, and metadata). Published projects are visible in Project Web App. The Archive tables contain backed-up and older versions of projects. The Reporting tables are the staging area for generating reports and online analytical processing (OLAP) cubes. Data in the Reporting tables is updated nearly in real-time, is comprehensive, and is optimized for read-only report generation. Only the Reporting table schema is documented. You should access the Drafts, Published, and Archive tables only through the Project Server Interface. Note Access to the Reporting tables is not supported in Project Online. You must use the Project Web App OData feed to access the data in the Reporting tables. You can add data tables, fields (properties), and entities that are not defined in the Project Server 2013 database schema. If you do, you must also provide the full stack of a custom assembly, Web service, business objects, and data access. Note These additions will not be automatically upgraded to future versions of Project Server.

111 Plan for administrative and service accounts in Project Server /13/ min to read Edit Online Summary: Learn about the accounts that you must plan for and the deployment scenarios that affect account requirements in Project Server Applies to: Project Server 2013 Use this article to plan for the account requirements and recommendations for accounts that are required to install, configure, and use Project Server You must provide credentials for these accounts during Setup and configuration. This article does not discuss accounts that you do not have to configure or provide credentials for. Administrative and service accounts that are required by Project Server 2013 This section lists and describes the accounts that are required by Project Server Note All Project Server 2013 and SharePoint Server 2013 service accounts must be granted interactive logon permissions for the computer where the service is running. By default, such permissions are normally granted when a new account is set up. However, you may have to make manual adjustments if your organization normally denies interactive logon permissions for service accounts. The following table describes the standard account requirements for Project Server Standard account requirements for Project Server 2013 ACCOUNT PURPOSE REQUIRED PERMISSIONS Setup user account The user account that is used to run: Setup on each server computer SharePoint Products Configuration Wizard The Psconfig command-line tool Log in with this account when you install SharePoint Server 2013 and Project Server This must be a domain account. IMPORTANT - This account may already exist if you are deploying Project Server 2013 to an existing SharePoint Server 2013 farm. This account must be a member of the local Administrators group on each application server in the farm. This account must be: a member of the local Administrators group on each application server in the farm. A member of the sysadmin Server Role in SQL Server. If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.

112 ACCOUNT PURPOSE REQUIRED PERMISSIONS Server farm account Application Pool Workflow Proxy This account is also known as: Farm administrator account Database access account This account servers as the following: The application pool account for the SharePoint Central Administration Web site The process account for the SharePoint 2013 Timer (SPTimerV4) service IMPORTANT - This account may already exist if you are deploying Project Server 2013 to an existing SharePoint Server 2013 farm. Runs the application pool associated with the Project Server service application. NOTE - This account may already exist if you are deploying Project Server 2013 to an existing SharePoint Server 2013 farm. However, we recommend that you create a separate account for the Project Server service application. Runs Project Server workflow activities. This account makes the Project Server Interface (PSI) calls associated with each workflow. NOTE - This account is only used for workflows that use the SharePoint Server 2010 workflow platform. Additional permissions are automatically granted for this account when Project Server 2013 is installed and when additional application servers are added to the farm. A logon is automatically created for this account in SQL Server, and that logon is automatically added to the following SQL Server Server Roles: dbcreator fixed server role securityadmin fixed server role db_owner fixed database role for all databases in the server farm The following SQL Server roles and permissions are automatically assigned to this account: Database owner role for content databases associated with the Web application Read/write access to the associated Service Application database Read from the configuration database Additional permissions for this account on front-end Web servers and application servers are automatically granted by Project Server This domain account must also be configured as a Project Server user account that has the following permissions: Global permissions: -Log On -Manage Users and Groups -Manage Workflow and Project Detail Pages Category permissions: -Open Project -Save Project to Project Server NOTE - If you are using SharePoint Permission mode, add this account to the Administrators for Project Web App security group. Accounts and groups for business intelligence In addition to the accounts listed earlier in this article, the following accounts and Active Directory directory service groups are required when you configure reporting for Project Server Accounts and groups required for reporting in Project Server 2013 ACCOUNT PURPOSE REQUIRED PERMISSIONS Report Authors Group Active Directory security group to which you add users who will create reports. This group requires db_datareader permissions on the Project Web App database.

113 ACCOUNT PURPOSE REQUIRED PERMISSIONS Report Viewers Group External Report Viewers Group Secure Store Target Application account Active Directory security group to which you add users who will view reports. (Optional.) Active Directory security group for users who do not have a Project Web App user account but require access to the Project Server 2013 Business Intelligence Center to view reports. This account provides the credentials necessary for report viewers to view reports generated from data in the Project Web App database. This account is used as part of Secure Store configuration. None. (This group is used as part of Secure Store configuration.) This group requires read permissions to the Business Intelligence Center site. This account must have db_datareader permissions on the Project Web App database. We recommend that you add this account to the Report Authors Active Directory group described earlier in this section to give it the necessary permissions.

114 Project Server 2016 architecture 12/13/ min to read Edit Online Summary: Learn about the general architecture of Project Server Applies to: Project Server 2016 Project Server 2016 architecture includes association of the Project Application Service with SharePoint site collections, the client-side object model (CSOM) for remote access, an OData interface for reporting, and remote event receivers that are accessible by multiple Project Server installations. In addition to on-premises custom solutions, you can create apps that include remote event receivers and components that access the CSOM and OData interfaces. The front-end tier includes Project Professional 2016, Project Web App, and third-party apps. Client applications communicate with the middle tier through the Project Server Interface (PSI) or through the CSOM endpoints, which in turn communicate with the PSI and the business object layer. Database access is integrated in the business objects. The Project Server Eventing System can access both local event handlers and remote event receivers. The Project Calculation Service implements the Project scheduling engine within Project Server. General architecture Below is a generalized view of the Project Server 2016 architecture, including the Project Service Application and several client applications including Project Professional 2016.

115 The following general comments apply to the illustration above: Project Online: You can create apps that use the CSOM, REST, and OData interfaces. An app package can also install remote event receivers in a custom web service on a local server, on an Azure server, or on Microsoft Azure. Project Online does not support third-party on-premises solutions, the WCF interface, the ASMX interface, or local event handlers. Event receivers: Event receivers can also be called event handlers. Project Online supports registration of remote Project Server event receivers, which can be used by a Project Web App instance in the cloud or by an on-premises Project Server installation. An on-premises Project Server installation supports remote event receivers and local full-trust event handlers. Programmatic interfaces: For third-party apps, Project Online exposes the HTTP/HTTPS interface (including REST), the CSOM interface, an OData service for the CSOM, and an OData service for reporting. For third-party client applications that are on-premises (on the Intranet), you can use the WCF interface for

116 the PSI, or you can use the CSOM, OData, and REST interfaces through HTTP. The Project Web App and Project Professional 2016 clients both use the WCF interface. In a single-server installation, the front-end ASMX web services, CSOM, and REST internally call the back-end WCF services. The OData service for reporting is implemented by the internal OData.svc WCF service. You can get the Service Metadata Document for the reporting data by using The OData service for the CSOM is intended for platforms such as Windows RT, ios, and Android, where you can use the REST interface with UNRESOLVED_TOKEN_VAL(ecmascriptshort) in HTML pages. Workflows: Declarative workflows are offloaded to Workflow Manager for processing. Workflow Manager can run on a separate server in the SharePoint farm, on Microsoft Azure in the cloud, or on a single Project Server computer for testing or demonstrations. Coded workflows that are developed with Visual Studio are processed in the workflow runtime within SharePoint. Perimeter network (DMZ): The illustration above does not show that an on-premises front end server can be isolated by an additional firewall in a perimeter network (also known as a "demilitarized zone" or DMZ). A perimeter network can allow Internet clients to access SharePoint and Project Server across a firewall. SharePoint Web Services: The illustration above does not show the SharePoint infrastructure, such as the back-end SharePoint Web Services application, which is part of SharePoint Server When you install Project Server, the Project Service Application is added to the SharePoint Web Services. The front-end tier includes third-party applications, Project Professional, and Project Web App. A browser displays ASP.NET 4.0 pages (.aspx pages) in Project Web App. The Project Web App pages use Project Server Web Parts that communicate with the PSI and also use standard SharePoint Web Parts. The Project Web App components of Project Server use the SharePoint Server 2016 configuration database for project site setup and the content database for all other information. There is no longer a separate Project Server database.

117 Install and configure for Project Server 12/13/ min to read Edit Online Summary: Deployment articles for Project Server help you prepare to install and configure it. Articles include information about deployment scenarios, step-by-step installation instructions, post-installation configuration steps, and upgrade information. This "install and configure" section includes information about deployment scenarios, step-by-step installation instructions, and post-installation configuration steps. This section also covers information about upgrading to Project Server Articles about installing and configuring Project Server 2016 The following articles about installing and configuring Project Server 2016 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Deploy Project Server 2016 Upgrade to Project Server 2016 DESCRIPTION A list of articles about how to install Project Server 2013 in a server farm environment. A list of articles about how to upgrade to Project Server Articles about installing and configuring Project Server 2013 The following articles about installing and configuring Project Server 2016 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Deploy Project Server 2013 Upgrade to Project Server 2013 DESCRIPTION A list of articles about how to install Project Server 2013 in a server farm environment. A list of articles about how to upgrade to Project Server 2013.

118 Deploy Project Server /14/ min to read Edit Online Summary: Learn how to deploy Project Server Applies to: Project Server 2016 This series of articles describes the steps necessary to install Project Server Be sure you've planned your deployment and reviewed thesoftware requirements before you begin. Deploying Project Server 2016 consists of the following steps: 1. Install SharePoint Server Project Server 2016 is part of SharePoint Server 2016 Enterprise Edition. Before you can configure Project Server 2016, you must install SharePoint Server Configure Project Server Unlike prior versions of Project Server, Project Server 2016 does not require a separate install from SharePoint Server Once you have installed SharePoint Server 2016, you can configure Project Server Create a Project Web App site - Once the initial Project Server 2016 configuration within SharePoint Server 2016 is completed, you can create a Project Web App site. See also Upgrade to Project Server 2016

119 Install and configure Project Server /13/ min to read Edit Online Summary: Configure Project Server 2016 on a SharePoint Server 2016 farm. Applies to: Project Server 2016 Project Server 2016 runs as a service application under SharePoint Server It is included as part of the SharePoint Server 2016 Enterprise installation, though it is licensed separately. This article describes configuring Project Server 2016, including provisioning the Project Server Service Application. Project Server 2016 is only available on SharePoint Server 2016 Enterprise. Be sure you have installed SharePoint Server 2016 before starting the procedures in this article. Also, be sure that the State Service is running on your SharePoint farm. Configure Project Server 2016 Project Server 2016 requires a license in order to operate, and you must enable Project Server 2016 by using your license key before you can create a Project Web App site. (If you're not sure if Project Server 2016 has already been enabled, use the Get-ProjectServerLicense cmdlet to check.) To activate Project Server Open the SharePoint 2016 Management Shell as Administrator. 2. Type the following to enable Project Server 2016: Enable-ProjectServerLicense -Key <LicenseKey> Creating a service application Project Server 2016 runs as a service application in SharePoint Server 2016, so the first thing to do is check to see if you already have a Project Server Service Application configured. Check for a Project Server Service Application 1. In the SharePoint Central Administration website, under Application Management, click Manage service applications. 2. Check the service applications list for a Project Server Service Application. If you already have a Project Server Service Application, you can go ahead and configure a Project Web App site. Otherwise, the first step in creating a Project Server Service Application is to register a managed account. For this, you'll need a domain account that you can use to run the application pool for the Project Server Service Application. To register a managed account 1. On the Central Administration home page, in the left navigation, click Security. 2. On the Security page, in the General Security section, click Configure managed accounts. 3. On the Managed Accounts page, click Register Managed Account. 4. Type the user name and password of the domain account that you are registering. 5. Optionally, select the Enable automatic password change check box if you want SharePoint Server to

120 manage password changes for this account. 6. Click OK. After the application pool account has been registered with SharePoint Server, the next step is to create the Project Server service application. Use the following procedure to create the service application. To create a Project Server service application 1. On the Central Administration home page, in the Application Management section, click Manage service applications. 2. On the Manage Service Applications page, on the ribbon, click New, and then click Project Server Service Application. 3. On the Create Project Web App service application page: 4. Type a name for the service application in the Project Web App service application name box. 5. In the Application Pool section, type the name of the application pool you want to create in the Application pool name box. 6. Select the Configurable option, and choose the managed account that you want to use to run the application pool. 7. Click OK. The next step is to determine how you want to deploy Project Web App. Go to the next article, Deploy Project Web App. See also Project forums

121 Deploy Project Web App 12/13/ min to read Edit Online Summary: Determine whether to deploy Project Web App to a new site collection or add it to an existing site collection. Applies to: Project Server 2016 Before we get started configuring Project Web App, here are two important things if you've used earlier versions of Project Server: If you are upgrading from a previous version of Project Server, you will deploy Project Web App as part of the upgrade process. Read Upgrade to Project Server 2016 instead of this article. In Project Server 2016, a Project Web App site is created by using Microsoft PowerShell. There's no longer a Create Project Web App Instance button in the SharePoint Central Administration website. We'll give you the details in the topics below. There are two options for deploying Project Web App. You can either create a Project Web App site as the top level of a new site collection, or you can add a Project Web App site to an existing site collection. If you are looking for a clean environment to begin managing projects in Project Web App, consider creating your Project Web App site as the top level site in a new site collection. For step-by-step instructions on how to create a Project Web App site as the top level site in a new site collection, see Deploy Project Web App with a new site collection (Project Server 2016). If you have existing sites where you have SharePoint task list projects and you want to add Project Server functionality to them, you can add a Project Web App site to that site collection. For step-by-step instructions on how to add a Project Web App site to an existing site collection, see Deploy Project Web App in an existing site collection (Project Server 2016) See also Project forums

122 Deploy Project Web App with a new site collection (Project Server 2016) 12/13/ min to read Edit Online Summary: Learn how to deploy an instance of Project Web App along with a Project Web App site in a new site collection. Applies to: Project Server 2016 Create a top-level web site If a top-level web site does not exist for the web application where you want to create a Project Web App site, you must first create one. Use the following procedure to create a top-level web site if needed. To create a top-level Web site 1. In the SharePoint Central Administration website, in the Application Management section, click Create site collections. 2. Choose a Web application from the Web Application drop-down menu. 3. Type a title for the site collection in the Title box. 4. In the Template Selection section, choose a template for the site. Note Project Server 2016 does not require a specific template. You can choose one appropriate for your organization. 5. In the Primary Site Collection Administrator section, type the name of the account that you want to use for the site administrator. 6. Click OK. After you have created the top-level web site, you must grant users access to the site. Use the following procedure to grant read access to the top-level site. To set Read permissions on the top-level Web site 1. Navigate to the root site (that is, 2. At the top of the page, click Share. 3. On the Share dialog box, click Show Options. 4. From the Select a group or permission level, choose Visitors [Read]. 5. In the Enter names or addresses text box, typeeveryone. 6. Click Share. Create a Project Web App site

123 Important When you create a new Project Web App site in conjunction with a new site collection, we recommend that you use a separate SharePoint Server 2016 content database for the Project Web App site and its associated project workspaces. To correctly isolate the Project Web App site in its own content database, you must deploy Project Web App at a time when other administrators are not creating new sites on the Web application where you are deploying Project Web App. By putting Project Web App and its associated project workspaces in a separate content database, you greatly simplify site migration and backup and restore procedures. Creating a Project Web App site takes five basic steps: 1. Create a content database to host the Project Web App site and its associated project workspaces. 2. Create the Project Web App site itself. 3. Lock down the Project Web App content database to prevent additional site collections being added. Important Ensure that no other administrators are adding site collections to the Web application where you plan to deploy Project Web App while you are performing the procedures in this section. To create a content database 1. In SharePoint Central Administration, in the Application Management section, click Manage content databases. 2. Click Add a content database. 3. In the Web Application section, choose the Web application where you plan to deploy the Project Web App site. 4. In the Database Name and Authentication section, type the database server name where you plan to deploy your Project Web App databases, and type a name for the database. 5. Click OK. After the content database has been created and configured, the next step is to create the Project Web App site itself. To create a Project Web App site in a new site collection, you run the New-SPSite Microsoft PowerShell cmdlet to create the site in the content database that you just created, and then run Enable-SPFeature to turn on the Project Web App site collection features. Run the following script to create the Project Web App site. New-SPSite -ContentDatabase ContentDBName -URL SiteCollectionURL/PWASiteName -Template pwa#0 Enable-SPFeature pwasite -URL SiteCollectionURL/PWASiteName For example: New-SPSite -ContentDatabase PWA_Content -URL -Template pwa#0 Enable-SPFeature pwasite -URL After the Project Web App site has been provisioned, verify that it was created in the content database that you created. Use the Get-SPSite Microsoft PowerShell command, passing the new content database as a parameter:

124 To verify the Project Web App site location From the Microsoft PowerShell command prompt, type the following command and then press ENTER: Get-SPSite -ContentDatabase The command should return the URL for your Project Web App site and no other URLs. Note If additional URLs beyond that of the Project Web App site are listed in the content database, delete the Project Web App site and restart the procedure with a new content database. After the Project Web App site is in the desired content database, you must lock down the database to prevent SharePoint Server 2016 from adding additional site collections to the database. This is performed by configuring the maximum number of sites for the content database to one. Note Configuring this setting does not prevent new project workspace sites from being created. To lock down the content database 1. In SharePoint Central Administration, in the Application Management section, click Manage content databases. 2. In the Database Name column, click the link for the content database that you created. 3. In the Database Capacity Settings section: 4. In the Number of sites before a Warning event is generated box, type0. 5. In the Maximum number of sites that can be created in this database box, type1. 6. Click OK. You can now access the new Project Web App site. See also Deploy Project Web App in an existing site collection (Project Server 2016) Project forums

125 Deploy Project Web App in an existing site collection (Project Server 2016) 12/13/ min to read Edit Online Summary: Deploy an instance of Project Web App to an existing site collection and create a Project Web App site. Applies to: Project Server 2016 Deploying an instance of Project Web App to an existing site collection consists of the following: Create a Project Web App site Enable the Project Web App site collection features If you have already enabled the Project Web App site collection features (for example, if you imported SharePoint list projects into Project Web App), then a Project Web App instance already exists in the site collection, and you can proceed to create a Project Web App site. Note Only one Project Web App site can be created per content database. For information on enabling the Project Web App site collection features, see Enable the Project Web App site collection features in Project Server For information on creating a Project Web App site in an existing site collection, see Create a PWA site in an existing site collection. See also Deploy Project Web App with a new site collection (Project Server 2016) Project forums

126 Enable the Project Web App site collection features in Project Server /13/ min to read Edit Online Summary: Enable the Project Web App site collection features to allow the import of SharePoint list projects into Project Web App. Applies to: Project Server 2016 Enabling the Project Web App site collection features adds additional functionality to the site collection that allows you to import SharePoint list projects into Project Web App. Enable the Project Web App site collection features The Project Web App site collection features are enabled by using the Enable-SPFeature PowerShell cmdlet. Use the following PowerShell script to enable the Project Web App site collection features. Enable-SPFeature pwasite -URL SiteCollectionURL For example: Enable-SPFeature pwasite -URL After the Project Web App site collection features have been activated for the site collection, you can add a Project Center web part and begin importing SharePoint list projects into Project Web App. If you want to add a Project Web App site to the site collection, see Create a PWA site in an existing site collection. See also New-SPProjectDatabase Enable-SPFeature Get-SPWeb Project forums

127 Create a PWA site in an existing site collection 12/13/ min to read Edit Online Summary: Add a Project Web App site to an existing site collection. Applies to: Project Server 2016 You can add a Project Web App site to an existing site collection. Doing so will allow you to take full advantage of Project Server 2016 and Project Web App functionality for the projects in that site collection. In order for a Project Web App site to function properly, the Project Web App site collection features must be enabled. If you have not already done so, enable the Project Web App site collection features on the site collection where you want to deploy the Project Web App site. To create a Project Web App site in an existing site collection, you run the New-SPWeb Microsoft PowerShell cmdlet to create the site. Run the following script to create the Project Web App site. New-SPweb -URL SiteCollectionURL/PWASiteName -Template pwa#0 For example: New-SPweb -URL -Template pwa#0 The Project Web App site is now available at the URL that you specified. See also New-SPWeb Upgrade-SPProjectWebInstance Project forums

128 Configure OLAP cubes for Project Web App 12/13/ min to read Edit Online Summary: Set up OLAP cubes for Project Web App in Project Server Applies to: Project Server 2016 This article describes how to configure a SQL Server Analysis Services cube for Project Web App. You must follow the procedures in this article for each instance of Project Web App that you create. In this article: Before you begin Configure the Analysis Services service account Build an OLAP cube in Project Web App Grant access to the Project Web App OLAP cube Before you begin Before you begin: You need an instance of SQL Server Analysis Services where you can build an OLAP cube You also need the name of the account that is running the SQL Server Analysis Services service for one of the procedures in this article. Ensure that the SharePoint system account is an OLAP Administrator on that instance of SQL Server Analysis Services. You must have installed the SQL Server 2014 Analysis Management Objects (AMO) on each Application and Front-end role servers in the farm. (Download the SQL Server 2014 Analysis Management Objects.) Configure the Analysis Services service account To build OLAP cubes, the account running the Analysis Services service must have read access to the Project Web App in the SharePoint Content database. This access is granted using the PSDataAccess database role in SQL Server. The first step is to create a SQL Server login for the account running the SQL Server Analysis Services service. Use the following procedure to create a login for the SQL Server Analysis Services service account. Note If a login already exists for the SQL Server Analysis Services service account, you can skip this procedure. To create a login for the Analysis Services service account 1. In SQL Server Management Studio, connect to the instance of the database engine where your Project Web App is located. 2. In Object Explorer, expand Security. 3. Right-click Logins, and then click New Login.

129 4. In the Login name box, type the name of the Active Directory account that is running the Analysis Services service. 5. Click OK. Once the login has been created, you must grant the login access to the SharePoint content database where your Project Web App site is located. Use the following procedure to configure database access. To grant database access to the Analysis Services service account 1. In SQL Server Management Studio, connect to the database engine. 2. In Object Explorer, expand Security. 3. Double-click the login for the Analysis Services service. 4. In the Select a page section, click User Mapping. 5. Select the Map check box for the SharePoint content database where your Project Web App site is located, and then, in the Database role membership for: section, select the PSDataAccess check box. 6. Click OK. The next step is to build an OLAP cube. Build an OLAP cube in Project Web App In order to configure the needed permissions in SQL Server Analysis Services, the OLAP cube must be created. Even if you do not plan to use the cube right away, you will need to build one now in order to configure the needed user access requirements. Use the following procedure to build an OLAP cube. To build an OLAP cube 1. In Central Administration, under Application Management, click Manage service applications. 2. Click the Project Server service application. 3. Hover over the instance of Project Web App for which you want to build a cube, click the arrow that appears, and then click Manage. 4. On the Project Web App settings page, under Queue and Database Administration, click OLAP Database Management. 5. On the OLAP Database Management page, in the OLAP Database Name column, click the DatabaseName link. 6. On the OLAP Database Build Settings page: 7. In the Analysis Services Server box, type the name of the instance of Analysis Services where you want to build the cube. 8. In the Analysis Services Database to be created box, type a name for the OLAP database. 9. Click Save. 10. On the OLAP Database Management page, select the row in the table for the cube that you just configured, and then click Build Now. 11. Monitor the Status field on the OLAP Database Management page until the status is Build Success! After you have built the cube, you can grant users access to it.

130 Grant access to the Project Web App OLAP cube To grant users access to the cube, you must add the following groups and accounts to the default ProjectServerViewOlapDataRole role in the cube: If you're accessing the cube using Windows authentication, such as through Excel, your user account must be a member of the ProjectServerViewOlapDataRole role in the cube. Consider using Active Directory Directory Services groups to manage user access to the cube. If you're using Active Directory synchronization with Project Server, those groups may contain the users to whom you want to grant cube access. If you're accessing the cube using Secure Store, such as when using Excel Online, the credentials of the Secure Store target application must be a member of the ProjectServerViewOlapDataRole role in the cube. Use the following procedure to grant users access to the OLAP cube. To grant user access to the OLAP cube 1. In SQL Server Management Studio, connect to Analysis Services. 2. In Object Explorer, expand Databases. 3. Expand the cube that you just created. 4. Double-click the ProjectServerViewOlapDataRole role. 5. In the left pane, select the Membership page. 6. On the Membership page, click Add. 7. On the Select Users or Groups dialog box, click Object Types. 8. On the Object Types dialog box, select the Groups check box, and then click OK. 9. On the Select Users or Groups dialog box, type the name of the Report Authors Active Directory group and the name of the data access account for the ProjectServerApplication Secure Store target application. Also type the name of any additional users or groups to which you want to grant cube access. 10. Click OK. 11. Click OK. See also Project forums

131 Deploy Project Server /15/ min to read Edit Online Summary: A list of articles about how to install Project Server 2013 in a server farm environment. Applies to: Project Server 2013 This series of articles describes the steps necessary to install Project Server 2013 in a server farm environment. This includes installing and configuring Project Server, deploying Project Web App, and configuring reporting. Before you deploy Project Server 2013, we highly recommend that you review the articles in the section named IT Pro Planning for Project Server. TechNet articles about deploying Project Server 2013 to a server farm environment The following articles about deploying Project Server 2013 to a server farm environment are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Installation and deployment overview for Project Server 2013 Prepare for deployment Configure SQL Server and Analysis Services in Project Server 2013 Install SharePoint Server 2016 (Project Server 2013) Install and configure Project Server 2013 Deploy Project Web App Configure reporting for Project Server 2013 DESCRIPTION Learn about the steps involved in installing Project Server 2013 in a server farm environment. Ensure that you have access to the necessary accounts and permissions to install Project Server Configure SQL Server and SQL Server Analysis Services (SSAS) settings prior to installing Project Server Install SharePoint Server 2013 and create a server farm prior to installing Project Server Install Project Server 2013 on a SharePoint Server 2013 farm and create a Project Server service application. A Project Web App site can be deployed in conjunction with creating a new site collection, or it can be added to an existing site collection. Configure reporting for Project Web App and configure Secure Store and Excel Services settings to enable the Project Web App sample reports.

132 CONTENT DESCRIPTION Add an application server to a farm Add a new SharePoint Server 2013 application server with Project Server 2013 to an existing farm.

133 Install Project Server 2013 to a stand-alone computer 12/21/ min to read Edit Online Summary: Set up a simple Project Server 2013 installation for demonstration purposes. Applies to: Project Server 2013 Project Server 2013 can be installed in a stand-alone configuration that uses SQL Server 2008 R2 Express Edition with SP1. This configuration is useful for demonstration, but should not be used for a production environment. The stand-alone configuration has fewer features than a full farm installation. SQL Server Analysis Services (SSAS) and OLAP are not present in the stand-alone configurations. (Analysis Services and OLAP functionality can be configured to use a different instance of SQL Server if you want.) IMPORTANT We recommend installing the standalone configuration on a computer that has at least 24GB of RAM. To install Project Server 2013 in stand-alone mode, you must first install SharePoint Server 2013 in stand-alone mode. This includes installing the prerequisites for SharePoint Server To install SharePoint Server 2013 prerequisites 1. On the SharePoint Server 2013 DVD, run default.hta. 2. On the SharePoint Server 2013 first page, click Install software prerequisites. 3. Follow the wizard to complete the installation. NOTE - Depending on your configuration, you may have to restart your computer during this process. 4. When the wizard has finished, click Finish. 5. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following hotfixes: KB KB KB KB Once the software prerequisites have been installed, restart the computer before installing SharePoint Server After you have restarted the computer, use the following procedure to install SharePoint Server 2013 in standalone mode. To install SharePoint Server On the SharePoint Server 2013 DVD, run default.hta. 2. ON the SharePoint Server 2013 first page, click Install SharePoint Server. 3. On the Enter your Product Key page, type your product key, and then click Continue. 4. On the Read the Microsoft Software License Terms page, read the license agreement and accept the terms by selecting the I accept the terms of this agreement check box. 5. Click Continue. 6. On the Choose the installation you want page, select the Stand-alone option, and then click Install Now. SharePoint Server 2013 will install.

134 7. When the installation is complete, click Close. The SharePoint Products Configuration Wizard starts. 8. On the Welcome to SharePoint Products page, click Next. 9. On the warning dialog box, click Yes. 10. On the Configuration Successful page, click Finish. 11. On the Template Selection page, select one of the following options, and then click OK: In the Template Selection section, click a predefined template. In the Solutions Gallery section, click Solutions Gallery, and customize your own site template. 12. On the Set Up Groups for this Site page, specify who should have access to your site, and then either create a new group or use an existing group for these users by doing one of the following: To create a new group, click Create a new group, and then type the name of the group and the members that you want to be part of this group. To use an existing group, click Use an existing group, and then select the user group in the Item list. 13. Click OK. Once SharePoint Server 2013 is installed, the next step is to install Project Server 2013 and run the SharePoint Products Configuration Wizard. To install Project Server On the SharePoint Server 2013 DVD, run default.hta. The Setup menu opens. > [!NOTE] > default.hta may run automatically when you insert the disk. 2. On the Start page, click Install Project Server. 3. On the Enter your Product Key page, type your product key, and then click Continue. 4. In the End User License Agreement page, review the terms of the agreement. To accept the agreement, select the I accept the terms of this agreement check box. 5. Click Continue. 6. On the Choose a file location page, click Install Now. 7. When the installation is complete, click Close. The SharePoint Products Configuration Wizard starts. 8. On the Welcome to SharePoint Products page, click Next. 9. On the warning dialog box, click Yes. 10. On the Configuration Successful page, click Finish. When the SharePoint Products Configuration Wizard finishes, the system will automatically create a PWA site. This may take several minutes. When the site has been created, it can be accessed at NOTE The account that you used to install Project Server is automatically added to the Project Server Administrators group. See also Install SharePoint 2013 on a single server with a built-in database Deploy Project Server 2013 to a server farm environment Hardware and software requirements for Project Server 2013

135 Deploy Project Server 2013 to a server farm environment 12/13/ min to read Edit Online Summary: A list of articles about how to install Project Server 2013 in a server farm environment. Applies to: Project Server 2013 This series of articles describes the steps necessary to install Project Server 2013 in a server farm environment. This includes installing and configuring Project Server, deploying Project Web App, and configuring reporting. Before you deploy Project Server 2013, we highly recommend that you review the articles in the section named IT Pro Planning for Project Server. Articles about deploying Project Server 2013 to a server farm environment The following articles about deploying Project Server 2013 to a server farm environment are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Installation and deployment overview for Project Server 2013 Prepare for deployment Configure SQL Server and Analysis Services in Project Server 2013 Install SharePoint Server 2013 (Project Server 2013) Install and configure Project Server 2013 Deploy Project Web App Configure reporting for Project Server 2013 DESCRIPTION Learn about the steps involved in installing Project Server 2013 in a server farm environment. Ensure that you have access to the necessary accounts and permissions to install Project Server Configure SQL Server and SQL Server Analysis Services (SSAS) settings prior to installing Project Server Install SharePoint Server 2013 and create a server farm prior to installing Project Server Install Project Server 2013 on a SharePoint Server 2013 farm and create a Project Server service application. A Project Web App site can be deployed in conjunction with creating a new site collection, or it can be added to an existing site collection. Configure reporting for Project Web App and configure Secure Store and Excel Services settings to enable the Project Web App sample reports.

136 CONTENT DESCRIPTION Add an application server to a farm Add a new SharePoint Server 2013 application server with Project Server 2013 to an existing farm.

137 Installation and deployment overview for Project Server /13/ min to read Edit Online Summary: Learn about the steps involved in installing Project Server 2013 in a server farm environment. Applies to: Project Server 2013 This series of articles describes the steps necessary to install Project Server 2013 in a server farm environment. These steps include the following: Configure SQL Server and SQL Server Analysis Services Install SharePoint Server 2013 Install Project Server 2013 Create a Project Web App site Configure SQL Server and Analysis Services Configuring SQL Server and Analysis Services includes the following steps: Configure SQL Server network settings Configure Analysis Services Install SharePoint Server 2013 Project Server 2013 requires SharePoint Server 2013 Enterprise Edition. Before you can install and configure Project Server 2013, you must install SharePoint Server 2013 and create a server farm. This article guides you to the proper SharePoint Server 2013 resources to configure your server farm. Install and configure Project Server 2013 Once you have set up a SharePoint Server 2013 server farm, you can install Project Server The Project Server 2013 software must be installed on each application server and front-end web server in the farm. Once the Project Server 2013 software is installed and configured, you must configure a Project Server service application in SharePoint Server 2013 before you can create an instance of Project Web App. Create a Project Web App site Once the initial Project Server 2013 configuration within SharePoint Server 2013 is completed, you can configure an instance of Project Web App. Get started The first step, prior to installation, is to make sure you have the needed permissions to accomplish the required tasks. For more information, see Prepare for deployment. See also Project forums

138 Prepare for a deployment of Project Server /13/ min to read Edit Online Summary: Ensure that you have access to the necessary accounts and permissions to install Project Server Applies to: Project Server 2013 To successfully complete a deployment of Project Server 2013, the following permissions are required: Domain Administrator Required to set up two domain groups for report authors and report viewers. SQL Server Administrator Required for various SQL Server and SQL Server Analysis Services (SSAS) configuration tasks as denoted in Configure SQL Server and Analysis Services in Project Server Setup User Account Required to install Project Server This account is created when you install SharePoint Server Farm Administrator Required to configure a Project Web App site. This account is created when you install SharePoint Server Important Verify that you are installing SharePoint Server 2013 and Project Server 2013 on a clean instance of Windows Server that has not previously hosted SharePoint Server Uninstalling SharePoint Server 2010 does not completely clean all installed files, folders, registry entries and other components. Installing SharePoint Server 2013 and Project Server 2013 on such a server will likely cause issues. It is recommended that you reformat the hard drive and reinstall Windows Server if you do chose to use such a server. Creating users and groups in the Active Directory directory service Deploying Project Server 2013 requires that you have certain Active Directory users and groups available. The deployment instructions assume that the necessary groups already exist. If you have not yet created the necessary users and groups, do so now before deploying Project Server. For detailed information about the users and groups required for Project Server deployment, see Plan for administrative and service accounts in Project Server Configuring SQL Server and Analysis Services Before deploying your farm, you must configure SQL Server and SQL Server Analysis Services. If you are installing Project Server 2013 to an existing SharePoint Server farm, some of these steps may already be completed. We recommend that you confirm these settings before installing Project Server. To configure SQL Server and Analysis Services, follow the procedures in Configure SQL Server and Analysis Services in Project Server See also IT Pro Planning for Project Server Project forums

139 Configure SQL Server and Analysis Services in Project Server /13/ min to read Edit Online Summary: Configure SQL Server and SQL Server Analysis Services (SSAS) settings prior to installing Project Server Before you install SharePoint Server 2013 and Project Server 2013, you must first configure SQL Server and, if you're planning to use Project Server OLAP cubes, SQL Server Analysis Services. SQL Server Analysis Services must be deployed in Multidimensional mode. Note If you are installing Project Server 2013 to an existing SharePoint Server farm, some of these steps may already be completed. Complete the procedures in each section below: Configure SQL Server network settings Configure Analysis Services for building Project Server OLAP cubes Additionally, depending on the needs of your organization, you may want to do the following: Create a Project Web App database Create additional TempDB files We also recommend that you start the SQLSERVERAGENT service on the instance of SQL Server where your SharePoint Server databases are located. SharePoint Server and Project Server 2013 use the SQL Server Agent service to perform various database cleanup activities. When you have finished configuring SQL Server and Analysis Services, go to the next article, Install SharePoint Server 2016 (Project Server 2016). Configure SQL Server network settings For SharePoint Server and Project Server to work correctly, the associated instance of SQL Server must be configured to enable remote connections using TCP/IP. Use the following procedure to confirm that your instance of SQL Server is configured to allow remote TCP/IP connections. To configure SQL Server 2008 R2 or SQL Server 2012 network settings 1. Click Start, click All Programs, click Microsoft SQL Server 2008 R2 or Microsoft SQL Server 2012, click Configuration Tools, and then click SQL Server Configuration Manager. 2. In the left pane, expand SQL Server Network Configuration, and then select the instance of SQL Server where you will be installing Project Server 2013 databases. 3. In the right pane, ensure the Status for TCP/IP is Enabled. Configure Analysis Services for building Project Server OLAP cubes Project Server 2013 can build OLAP cubes in SQL Server Analysis Services (SSAS) for use in reporting. If you plan to

140 use the Project Server 2013 cube building feature, you must configure the Farm Administrator account to have administrative permissions in SQL Server Analysis Services for the instance of Analysis Services that you will be using with Project Server To add the Farm Administrator as an Analysis Services server administrator 1. Open SQL Server Management Studio. In the Connect to Server window, connect to the instance of Analysis Services that you are using with Project Server In SQL Server Management Studio, in Object Explorer, right-click your Analysis Services instance name, and then click Properties. 3. On the Analysis Services Properties page, in the Select a page pane, click Security. 4. Click Add. 5. On the Select Users, Computers, or Groups page, type the name of the Farm Administrator account. 6. Click OK. The Farm Administrator account appears in the Members list. 7. Click OK. Note For information about configuring user access for OLAP cubes, see Configure OLAP cubes for Project Web App. For information about managing OLAP databases in Project Server 2013, see OLAP database management in Project Web App. Create additional TempDB files Both Project Server 2013 and SharePoint Server 2013 make extensive use of TempDB during SQL transactions. To optimize performance, create additional TempDB files. As a rule, create an additional TempDB file for each processor (core) in the computer that is running SQL Server. Create the files on a separate partition from other database files. See also Install SharePoint Server 2016 (Project Server 2016) Project forums

141 Install SharePoint Server 2013 (Project Server 2013) 12/13/ min to read Edit Online Summary: Install SharePoint Server 2013 and create a server farm prior to installing Project Server Applies to: Project Server 2013 Before you can install Project Server 2013, you must install SharePoint Server 2013 and create a SharePoint Server 2013 farm. You must also start the State Service on the SharePoint farm. Important Project Server 2013 requires the Enterprise edition of SharePoint Server Prior versions of SharePoint Server and SharePoint Foundation 2013 are not supported. If you have a SharePoint Server 2013 farm configured and you are ready to install Project Server 2013, proceed to the next article, Install and configure Project Server If you have not yet installed SharePoint Server 2013, it is important to carefully plan your SharePoint Server 2013 farm before installing SharePoint Server For detailed information about planning your SharePoint Server 2013 farm, see Plan for SharePoint If you have completed the planning phase of your SharePoint Server 2013 deployment, see Multiple servers for a three-tier farm (SharePoint Server 2013) for detailed information about deploying SharePoint Server When you have completed SharePoint Server 2013 deployment, proceed to Install and configure Project Server See also Hardware and software requirements for Project Server 2013 Deployment Overview (SharePoint Server 2013) Determine hardware and software requirements (SharePoint Server 2013) Installation and deployment for SharePoint 2013 IT Pros Resource Center Project forums

142 Install and configure Project Server /13/ min to read Edit Online Summary: Install Project Server 2013 on a SharePoint Server 2013 farm and create a Project Server service application. Applies to: Project Server 2013 Project Server 2013 runs as a service application under SharePoint Server This article describes installing and configuring Project Server 2013, including provisioning the Project Server Service Application. Use the procedures that follow to install Project Server The Project Server 2013 software must be installed on each application server in the farm before you can run the SharePoint Products Configuration Wizard to integrate Project Server with SharePoint Server Important If you plan to use workflows with Project Server, you must install and configure the SharePoint 2013 Workflow platform in SharePoint Server For more information, see Installing and configuring workflow for SharePoint Server 2013 and theworkflow in SharePoint 2013 resource center. Important After you install Project Server 2013, it cannot be uninstalled from the farm. If you want to remove Project Server 2013 functionality, you can turn off the Project Application Service and delete the Project Server 2013 Service Application. Video demonstration This video shows the steps involved in installing Project Server 2013 and configuring a Project Server 2013 service application, as described in this article. Video: Install and configure Project Server 2013 Install and configure Project Server 2013 This section describes how to install Project Server The basic procedure is as follows: Install Project Server 2013 on each application server and Web server in the farm Run the SharePoint Products Configuration Wizard Refresh the installed products on the farm Note If you encounter an error during the installation process, check the log files that are located at \Program Files\Common Files\Microsoft shared\web server extensions\15\logs and consult the Project Forums ( LinkId=169001).

143 Complete the following procedure on each application server in the farm. To install Project Server On the Project Server 2013 DVD, run default.hta. The Setup menu appears. Note Default.hta may run automatically when you insert the disk. 2. On the Start page, click Install Project Server. 3. On the Enter your Product Key page, type your product key, and then click Continue. 4. In the End User License Agreement page, review the terms of the agreement. To accept the agreement, select the I accept the terms of this agreement check box. 5. Click Continue. 6. On the Choose a file location page, click Install Now. 7. When the installation is complete, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box. 8. Click Close. After the Project Server 2013 software has been installed on each web server and application server in the farm, you must run the SharePoint Products Configuration Wizard to integrate Project Server with SharePoint Server You must run this wizard on each web server and application server in the farm before you can start using Project Server. Complete the following procedure on each web server and application server in the farm. Note Run the SharePoint Products Configuration Wizard on one server at a time. Do not run it on multiple servers at the same time. To run the SharePoint Products and Technologies Configuration Wizard 1. Click Start, All Programs, Microsoft SharePoint 2013 Products, SharePoint 2013 Products Configuration Wizard. 2. At the Welcome to SharePoint Products and Technologies page, click Next. 3. A confirmation dialog message appears that displays a list of services that may have to be restarted. Click Yes. 4. On the Modify server farm Settings page, select the Do not disconnect from this server farm option, and then click Next. Note Depending on your configuration, this option may not appear. 5. If the server is hosting the SharePoint Central Administration website, the Modify SharePoint Central Administration Web Application Settings page appears. Select the No, this machine will continue to host the web site option, and then click Next.

144 Note Depending on your configuration, this option may not appear. 6. On the Completing the SharePoint Products Configuration Wizard page, click Next. 7. On the Configuration Successful page, click Finish. Configure services After Project Server 2013 is installed, the following configuration steps are required before creating a Project Web App site and using Project Server: Start the Project Server Application Service Create a Project Server service application Before you create a Project Server service application, you must start the Project Server Application Service on at least one application server in the farm. To start the Project Server Application Service 1. On the Central Administration home page, in the System Settings section, click Manage services on server. 2. On the Services on Server page, select the server where you want to run the Project Application Service from the Server drop-down list. 3. On the Service list, click Start next to Project Server Application Service. After you have started the Project Server service on the desired application servers in the farm, you must create a Project Server service application. Note While you can create more than one Project Server service application, doing so consumes additional system resources. We recommend that you create only one Project Server service application. A single service application supports multiple instances of Project Web App. The account that you plan to use for the application pool for the Project Server service application must be a registered account in SharePoint Server. If you have not already registered this account in SharePoint Server, use the following procedure to do so. To register a managed account 1. On the Central Administration home page, in the left navigation, click Security. 2. On the Security page, in the General Security section, click Configure managed accounts. 3. On the Managed Accounts page, click Register Managed Account. 4. Type the user name and password of the domain account that you are registering. 5. Optionally, select the Enable automatic password change check box if you want SharePoint Server to manage password changes for this account. 6. Click OK. After the application pool account has been registered with SharePoint Server, the next step is to create the Project

145 Server service application. Use the following procedure to create the service application. To create a Project Server service application 1. On the Central Administration home page, in the Application Management section, click Manage service applications. 2. On the Manage Service Applications page, on the ribbon, click New, and then click Project Server Service Application. 3. On the Create Project Web App service application page: 4. Type a name for the service application in the Project Web App service application name box. 5. In the Application Pool section, type the name of the application pool you want to create in the Application pool name box. 6. Select the Configurable option, and choose the managed account that you want to use to run the application pool. 7. Click OK. The next step is to determine how you want to deploy Project Web App. Go to the next article, Deploy Project Web App. See also Project forums

146 Deploy Project Web App 12/13/ min to read Edit Online Summary: Learn about the two ways to deploy a Project Web App site. Applies to: Project Server 2013 Project Web App deployment options There are two options for deploying Project Web App. You can either create a Project Web App site as the top level of a new site collection, or you can add a Project Web App site to an existing site collection. Note If you are upgrading from a previous version of Project Server, you will deploy Project Web App as part of the upgrade process. Read Upgrade to Project Server 2013 instead. If you are looking for a clean environment to begin managing projects in Project Web App, consider creating your Project Web App site as the top level site in a new site collection. (This was the only option available in Project Server 2010.) For step-by-step instructions on how to create a Project Web App site as the top level site in a new site collection, see Deploy Project Web App with a new site collection (Project Server 2013). If you have existing sites where you have SharePoint task list projects and you want to add Project Server functionality to them, you can add a Project Web App site to that site collection. For step-by-step instructions on how to add a Project Web App site to an existing site collection, see Deploy Project Web App in an existing site collection (Project Server 2013) For more information about Project Web App site architecture, watch the chalk talk video in the next section. Understanding Project Web App site options In this chalk talk, Microsoft Program Manager Chris Boyd discusses the differences between Project Web App in Project Server 2010 and Project Server 2013, and the new options available for Project Web App sites. Video: Project Web App site deployment options See also Project forums

147 Deploy Project Web App with a new site collection (Project Server 2013) 12/13/ min to read Edit Online Summary: Learn how to deploy an instance of Project Web App along with a Project Web App site in a new site collection. Applies to: Project Server 2013 Creating a Project Web App site with a new site collection creates a Project Web App database on the specified instance of SQL Server. Note If your organization requires databases to be created manually by a database administrator, have your database administrator see New-SPProjectDatabase and create the Project Web App database before you proceed with the procedures in this article. Video demonstration This video shows the steps involved in creating a Project Web App site with a new site collection in a Project Server 2013 farm, as described in this article. Video: Deploy Project Web App with a new site collection Create a top-level web site If a top-level web site does not exist for the web application where you want to create a Project Web App site, you must first create one. Use the following procedure to create a top-level web site if needed. To create a top-level Web site 1. Start SharePoint 2013 Central Administration.

148 For Windows Server 2008 R2: Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration. For Windows Server 2012: On the Start screen, click SharePoint 2013 Central Administration. If SharePoint 2013 Central Administration is not on the Start screen: Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration. 2. In Central Administration, in the Application Management section, click Create site collections. 3. Choose a Web application from the Web Application drop-down menu. Note If no Web application is available, you must create one. For more information, see Create a Web application (SharePoint Server 2013). 4. Type a title for the site collection in the Title box. 5. In the Template Selection section, choose a template for the site. Note Project Server 2013 does not require a specific template. You can choose one appropriate for your organization. 6. In the Primary Site Collection Administrator section, type the name of the account that you want to use for the site administrator. 7. Click OK. After you have created the top-level web site, you must grant users access to the site. Use the following procedure to grant read access to the top-level site. To set Read permissions on the top-level Web site 1. Navigate to the root site (that is, 2. At the top of the page, click Share. 3. On the Share dialog box, click Show Options. 4. From the Select a group or permission level, choose Visitors [Read]. 5. In the Enter names or addresses text box, type Everyone. 6. Click Share. Create a Project Web App site

149 Important When you create a new Project Web App site in conjunction with a new site collection, we recommend that you use a separate SharePoint Server 2013 content database for the Project Web App site and its associated project workspaces. To correctly isolate the Project Web App site in its own content database, you must deploy Project Web App at a time when other administrators are not creating new sites on the Web application where you are deploying Project Web App. By putting Project Web App and its associated project workspaces in a separate content database, you greatly simplify site migration and backup and restore procedures. Creating a Project Web App site takes five basic steps: 1. Temporarily lock down existing content databases. 2. Create a content database to host the Project Web App site and its associated project workspaces. 3. Create the Project Web App site itself. 4. Lock down the Project Web App content database to prevent additional site collections being added. 5. Unlock existing content databases. SharePoint Server 2013 uses a round-robin algorithm to determine the distribution of site collections across content databases. In order to deploy the Project Web App site to a specific content database, you have to lock down any existing content databases in the farm. The process does not affect user access; it only affects the distribution of new site collections. Note If you are deploying Project Web App to a new web application that will be dedicated to PWA, you can use the default content database created with that web application for Project Web App. In this case, there is no need to follow the following lockdown procedures. However, we do recommend that you set the Maximum number of sites that can be created in this database setting to1 for that content database after you deploy Project Web App. This helps avoid having additional site collections beyond Project Web App being created in that database in the future. To lock down your content databases, follow these steps for each content database associated with the Web application where you plan to deploy your Project Web App site. Important Ensure that no other administrators are adding site collections to the Web application where you plan to deploy Project Web App while you are performing the procedures in this section. To lock down a content database 1. In SharePoint Central Administration, in the Application Management section, click Manage content databases. 2. In the Current Number of Site Collections column, note the number of site collections for the database that you plan to lock down. 3. In the Database Name column, click the link for the content database that you want to lock down. 4. In the Database Capacity Settings section: 5. In the Maximum number of sites that can be created in this database box, type the existing number of site collections for this database (as noted in the Current Number of Site Collections column, earlier in

150 this procedure). Note Take note of the current value for this parameter. You will have to change it back to this value after the PWA site has been created. 6. In the Number of sites before a Warning event is generated box, type a lower number than the value that is used for Maximum number of sites that can be created in this database. Note Take note of the current value for this parameter. You will have to change it back to this value after the Project Web App site has been created. 7. Click OK. To create a content database 1. In SharePoint Central Administration, in the Application Management section, click Manage content databases. 2. Click Add a content database. 3. In the Web Application section, choose the Web application where you plan to deploy the Project Web App site. 4. In the Database Name and Authentication section, type the database server name where you plan to deploy your Project Web App databases, and type a name for the database. 5. Click OK. After the content database has been created and configured, the next step is to create the Project Web App site itself. To create a Project Web App site 1. In SharePoint Central Administration, in the Application Management section, click Manage service applications. 2. On the Manage Service Applications page, click the Project Server Service Application. 3. On the Manage Project Web App Sites page, click Create Project Web App Instance. 4. Complete the Create Project Web App Instance page as designated in the following table: OPTION DESCRIPTION Web Application Project Web App path Select a language Use Public URL The Web application for the Project Web App site. The path from the root site for this Project Web App site. The user interface language for this Project Web App site. Use this option if you want to host the Project Web App site on a root URL (for example,

151 OPTION DESCRIPTION Administrator Account Database server Quota for SharePoint content in this site Quota Warning for SharePoint content in this site The user account that will be added to the Administrators for Project Web App security group in this instance of Project Web App. You must use this account the first time that you access the Project Web App site. The instance of SQL Server where you want to host the Project Web App database. If your database administrator has already created a Project Web App database, specify the names of that database in the Project Web App database name text box. If the database was not previously created, it will be created automatically. The maximum site storage, in megabytes, for the Project Web App site. The site storage level, in megabytes, at which a warning message will be sent to the site administrator. 1. Click OK. Project Server starts the Project Web App site creation process. This may take some time. When the site creation process is complete, the status shown on the Project Web App site list is Provisioned. After the Project Web App site has been provisioned, verify that it was created in the content database that you created. Use the Get-SPSite Microsoft PowerShell command, passing the new content database as a parameter: To verify the Project Web App site location 1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. 2. On the Start menu, click All Programs. 3. Click Microsoft SharePoint 2013 Products. 4. Click SharePoint 2013 Management Shell. 5. From the Microsoft PowerShell command prompt (that is, PS C:\>), type the following command and then press ENTER: Get-SPSite -ContentDatabase The command should return the URL for your Project Web App site and no other URLs. Note If additional URLs beyond that of the Project Web App site are listed in the content database, delete the Project Web App site and restart the procedure with a new content database. After the Project Web App site is in the desired content database, you must lock down the database to prevent SharePoint Server 2013 from adding additional site collections to the database. This is performed by configuring the maximum number of sites for the content database to one. Note Configuring this setting does not prevent new project workspace sites from being created.

152 To lock down the content database 1. In SharePoint Central Administration, in the Application Management section, click Manage content databases. 2. In the Database Name column, click the link for the content database that you created. 3. In the Database Capacity Settings section: 4. In the Number of sites before a Warning event is generated box, type In the Maximum number of sites that can be created in this database box, type Click OK. After you have locked down your Project Web App content database, you can return any other content databases to their original values for Maximum number of sites that can be created in this database and Number of sites before a Warning event is generated. You can now access the new Project Web App site. See also Deploy Project Web App in an existing site collection (Project Server 2016) Project forums

153 Deploy Project Web App in an existing site collection (Project Server 2013) 12/13/ min to read Edit Online Summary: Deploy an instance of Project Web App to an existing site collection and create a Project Web App site. Applies to: Project Server 2013 Deploying an instance of Project Web App to an existing site collection consists of the following: Enable the Project Web App site collection features Create a Project Web App site If you have already enabled the Project Web App site collection features (for example, if you imported SharePoint list projects into Project Web App), then a Project Web App instance already exists in the site collection, and you can proceed to create a Project Web App site. Note Only one Project Web App site can be created per site collection. For information on enabling the Project Web App site collection features, see Enable the Project Web App site collection features in Project Server For information on creating a Project Web App site in an existing site collection, see Create a PWA site in an existing site collection. See also Deploy Project Web App with a new site collection (Project Server 2013) Project forums

154 Enable the Project Web App site collection features in Project Server /13/ min to read Edit Online Summary: Enable the Project Web App site collection features to allow the import of SharePoint list projects into Project Web App. Applies to: Project Server 2013 Enabling the Project Web App site collection features adds additional functionality to the site collection that allows you to import SharePoint list projects into Project Web App. Enabling the Project Web App site collection features consists of two steps: Create a Project Web App database Enable the Project Web App site collection features Video demonstration This video shows the steps involved in enabling the Project Web App site collection features, as described in this article. Video: Enable the Project Web App site collection features in Project Server 2013 Create a Project Web App database A Project Web App database is created using the New-SPProjectDatabase Microsoft PowerShell cmdlet. In order for the new database to be properly associated with the site collection where you want enable the Project Web App site collection features, you must use the Tag parameter to associate a unique string with this database. That string will be used later when you enable the site collection features. Run the following cmdlet to create a new Project Web App database. New-SPProjectDatabase -Name DatabaseName -ServiceApplication "ServiceApplicationName" -DatabaseServer SQLServerInstance -Tag String For example: New-SPProjectDatabase -Name ProjectWebApp1 -ServiceApplication "Project Service Application" -DatabaseServer Contoso-SQL -Tag "ProjectWebApp1DB" Note You can find the name of the Project Server service application in Central Administration by clicking Manage service applications under Application Management. Once you have created the new Project Web App database, the next step is to enable the Project Web App site collection features. Doing so will associate the database that you just created with the site collection.

155 Enable the Project Web App site collection features The Project Web App site collection features are enabled by using the Enable-SPFeature PowerShell cmdlet. Prior to running this cmdlet, you must set the PWA_TAG parameter of the site collection to match the Tag parameter that you set when you created the database. Use the following PowerShell script to set the PWA_TAG parameter and then enable the Project Web App site collection features. $web=get-spweb SiteCollectionURL $web.properties["pwa_tag"]="string" $web.properties.update() Enable-SPFeature pwasite -URL SiteCollectionURL For example: $web=get-spweb $web.properties["pwa_tag"]="projectwebapp1db" $web.properties.update() Enable-SPFeature pwasite -URL After the Project Web App site collection features have been activated for the site collection, you can add a Project Center web part and begin importing SharePoint list projects into Project Web App. If you want to add a Project Web App site to the site collection, see Create a PWA site in an existing site collection. See also New-SPProjectDatabase Enable-SPFeature Get-SPWeb Project forums

156 Create a PWA site in an existing site collection 12/13/ min to read Edit Online Summary: Add a Project Web App site to an existing site collection. Applies to: Project Server 2013 You can add a Project Web App site to an existing site collection. Doing so will allow you to take full advantage of Project Server 2013 and Project Web App functionality for the projects in that site collection. In order for a Project Web App site to function properly, the site collection must have a Project Web App database associated with it and the Project Web App site collection features must be enabled. If you have not already done so, create a Project Web App database and enable the Project Web App site collection features on the site collection where you want to deploy the Project Web App site. For more information, see Enable the Project Web App site collection features in Project Server To create a Project Web App site in an existing site collection, you run the New-SPWeb Microsoft PowerShell cmdlet to create the site and then run the Upgrade-SPProjectWebInstance to perform post-provisioning actions, including creating a Business Intelligence Center. Run the following script to create the Project Web App site. New-SPweb -URL SiteCollectionURL/PWASiteName -Template pwa#0 Upgrade-SPProjectWebInstance -Identity SiteCollectionURL -Confirm:$False For example: New-SPweb -URL -Template pwa#0 Upgrade-SPProjectWebInstance -Identity -Confirm:$False After you have created the Project Web App site and run Upgrade-SPProjectWebInstance, you must run iisreset on each application server in the farm. To run iisreset, open a command window, and type: iisreset /noforce The Project Web App site is now available at the URL that you specified. See also New-SPWeb Upgrade-SPProjectWebInstance Project forums

157 Configure reporting for Project Web App (Project Server 2013) 12/13/ min to read Edit Online Summary: Configure reporting for Project Web App and configure Secure Store and Excel Services settings to enable the Project Web App sample reports. Applies to: Project Server 2013 Project Server 2013 integrates the SharePoint Server 2013 Business Intelligence Center site template into each instance of Project Web App, which provides a central point for hosting the reports, dashboards, and report connections that can be auto-created or manually authored to provide access to reporting data in a given instance of Project Web App. The Business Intelligence Center can be used to host content created with Excel Services in SharePoint Server 2013, Visio Services in SharePoint, PerformancePoint Services in SharePoint, Power Pivot and SQL Server Reporting Services (SSRS). To configure reporting, you must do the following steps: Video demonstration Configure prerequisites Add a login for the report authors group in SQL Server Install SQL Server 2008 Analysis Management Objects Configure Excel Services settings Configure Secure Store Service settings Populate the Report Authors and Report Viewers Active Directory groups Video demonstration This video shows the steps involved in configuring reporting in Project Web App, as described in this article. Video: Configure reporting for Project Web App Configure prerequisites The procedures in this article require Excel Services and Secure Store. If you have not already deployed these services on SharePoint Server 2013, you must do so before proceeding with the procedures in this article. Note Both Excel Services and Secure Store run as service applications in SharePoint Server If you have already deployed these service applications in SharePoint Server 2013, you can use them with Project Server. There is no need to create new instances of these service applications for Project Server. For information about deploying Excel Services, see the following articles:

158 Excel Services overview Configure Excel Services in SharePoint Important The Excel Services application pool account requires access to the SharePoint content database that is associated with Project Web App. If the content database was created after Excel Services was configured, you must follow the procedure in Grant content database access to the managed account to grant the proper access. For information about deploying Secure Store, see the following articles: Plan the Secure Store Service (SharePoint Server 2013) Configure the Secure Store Service (SharePoint 2013) After both Excel Services and Secure Store have been configured on the farm, proceed with the procedures in the sections below. Accounts and security groups The following table describes the accounts and security groups that you will need for the various procedures in this article. Accounts and security groups for configuring reporting for Project Web App ACCOUNT Report Authors group Report Viewers group Secure Store Target Application account DESCRIPTION Active Directory security group to which you add users who will create reports, or any other users who need to access reports in Excel. This group is given read permissions to the Project Web App database via the PSDataAccess database role. Have your domain administrator create this group before proceeding with the procedures below. NOTE - If you have multiple instances of Project Web App and you want to isolate reporting access for each, you will need a Report Authors group for each instance of Project Web App. Active Directory security group to which you add users who will view reports. Have your domain administrator create this group before proceeding with the procedures below. NOTE - If you have multiple instances of Project Web App and you want to isolate reporting access for each, you will need a Report Viewers group for each instance of Project Web App. This account provides the credentials necessary for report viewers to view reports generated from data in the Project Web App database. This account must have read permissions on the Project Web App database via the PSDataAccess database role. TIP - We recommend that you add this account to the Report Authors Active Directory group described above to give it the necessary permissions. Add a login for the report authors group In order for a report author to be able to access the Project Web App database from Excel, it is necessary to configure SQL Server access and add a SQL Server logon. The logon must allow specific access to the Project Web

159 App database to get schema information and data. Use the domain group you created for report authors. Important Excel does not use the Secure Store Service for data access. Only Excel Services in SharePoint Server 2013 uses Secure Store. Users working with reports in Excel require direct database access. Perform the following procedure on the computer where your Project Web App database is located, or connect to the database engine remotely by using SQL Server Management Studio. To add a login for the report authors group 1. Click Start, All Programs, Microsoft SQL Server, SQL Server Management Studio. 2. Select the instance of the SQL Server database engine where your Project Server 2013 database resides, and then click Connect. 3. Expand Security, right-click Logins, and then click New Login. 4. On the General page, click Search. 5. Click Object Types, and select the Groups check box. 6. Click OK. 7. Type the name of the group you created for report authors. 8. Click Check Names. 9. Click OK. 10. Select the User Mapping page. 11. In the Users mapped to this login list box, select the row containing the Project Server 2013 Database. 12. Select the Map check box for the Project Server 2013 Database. 13. Select the PSDataAccess database role membership check box. 14. Click OK. Install SQL Server 2008 Analysis Management Objects If you do not already have the SQL Server 2008 R2 Analysis Management Objects (AMO) installed, you must install them on each application server in the farm. Note Use the SQL Server 2008 R2 version of AMO regardless of which version of SQL Server you are using to host your databases. Click to download the SQL Server 2008 R2 Analysis Management Objects ( LinkID=188448). Note After installing the AMO objects, restart the Project Application Service on each application server in the farm where it is running. This service is configured in the SharePoint Central Administration website in the System Settings section, Manage services on server.

160 Configure Excel Services settings You must configure trusted file locations for the Project Web App Sample Reports and Templates libraries. Follow this procedure twice: once for each library. To configure a trusted file location 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Excel Services service application. 3. On the Manage Excel Services page, click Trusted File Locations. 4. Click Add Trusted File Location. 5. In the Address box, type: For the Templates library: or For the Sample Reports library: 6. In the Trust Children section, confirm that the Children trusted check box is selected. 7. In the External Data section: 8. In the Allow External Data section, select the Trusted data connection libraries and embedded option. 9. In the Warn on Refresh section, clear the Refresh warning enabled check box. 10. Leave the remaining options at their default value, and then click OK. You must configure trusted data connection libraries in order to give users access to the connectors that link the report spreadsheets to the data in the Project Server Database and OLAP databases. As part of this process, you will need the URL of the data connection library in Project Web App (PWA). Use the following procedure to determine the URL of the data connection library in PWA. To determine the URL for the data connection library 1. On the Project Web App site, in the left navigation pane, click Reports. 2. In the left pane, click Data Connections. 3. On the Data Connections page, click the Open Menu button (...) for the English (United States) line (or the appropriate language for your locale). 4. On the toolbar, click View Properties. 5. On the Data Connections properties page, right-click the English (United States) (or the appropriate language for your locale) link, and then choose ** Properties**. 6. Copy the URL in the Location text box. To set up trusted data connection libraries 1. In Central Administration, in the Application Management, click Manage Service Applications. 2. Click the Excel Services service application.

161 3. Click Trusted Data Connection Libraries. 4. Click Add Trusted Data Connection Library. 5. In the Address box, paste the URL for the data connection library that you copied in the previous procedure. It should be in the following format: 6. Click OK. Configure Secure Store Service settings The sample reports included with each instance of Project Web App are configured to use a Secure Store target application called ProjectServerApplication. You must create this target application in order for the sample reports to work. Use the following procedure to create the target application. To create a Secure Store target application 1. On the SharePoint Central Administration website home page, in the Application Management section, click Manage Services Applications. 2. Click the Secure Store Service. 3. On the Secure Store Service page, select the Edit tab. 4. Click New. 5. On the Create New Secure Store Target Application page: 6. In the Target Application ID box, typeprojectserverapplication. 7. In the Display Name box, type a name for the Secure Store Target Application. 8. In the Contact box, type an address. 9. From the Target Application Type drop-down list, select Group. 10. Click Next. 11. On the Specify the credential fields for your Secure Store Target Application page, click Next. 12. On the Specify the membership settings page: 13. In the Target Application Administrators box, type the name of the user who will administer this target application. 14. In the Members box, type the name of the domain group you created for report viewers. 15. Click OK. 16. On the Secure Store Service Application page, select the check box for the target application that you just created. 17. On the ribbon, in the Credentials section, click Set. 18. On the Set Credentials for Secure Store Target Application (Group) dialog box, type the user name and password of the account you created for the secure store target application.

162 Important This account must have PSDataAccess permissions on the Project Web App database. We recommend that you add this account to the Report Authors Active Directory group to give it the required permissions. 19. Click OK. Populate the Report Authors and Report Viewers Active Directory groups To provide your users with the needed access to the Business Intelligence Center in Project Web App and the reports within, you must populate the Report Authors and Report Viewers Active Directory groups as follows: Report Authors group: Add the Active Directory accounts of users who will be creating reports using Excel. Report Viewers: Add the Active Directory accounts of Project Web App users who will be viewing reports in the Business Intelligence Center. Note If your report authors will also be viewing reports, you can add the Report Authors group to the Report Viewers group in Active Directory. OLAP cube access If you plan to use SQL Server Analysis Services OLAP cubes with Project Web App, then you must configure cube access for your users. For more information, see Configure OLAP cubes for Project Web App. See also Project forums

163 Configure OLAP cubes for Project Web App 12/13/ min to read Edit Online Summary: Set up OLAP cubes for Project Web App. Applies to: Project Server 2013 Important This scenario applies only to Project Server In this article: Before you begin Configure the Analysis Services service account Build an OLAP cube in Project Web App Grant access to the Project Web App OLAP cube Overview This article describes how to configure a SQL Server Analysis Services cube for Project Web App. You must follow the procedures in this article for each instance of Project Web App that you create. Note Due to changes in the security infrastructure in Project Server 2013, the View OLAP Data permission that existed in earlier versions of Project Server no longer exists in Project Server Cube access is now configured using the procedures in this article. Before you begin This article assumes that you have completed all of the steps in Configure reporting for Project Web App (Project Server 2013). The procedures in this article make use of the Active Directory groups and accounts that you created in the reporting configuration article. Before you begin, make sure you have the following: An instance of SQL Server Analysis Services where you can build an OLAP cube. The name of the account that is running the SQL Server Analysis Services service. The name of the Report Authors group that you created when you configured reporting for Project Web App The name of the Secure Store Target Application account that you created when you configured reporting for Project Web App. Note If this account is a member of the Report Authors group, then you will not need it for the procedures below.

164 Configure the Analysis Services service account To build OLAP cubes, the account running the Analysis Services service must have read access to the Project Web App database. This access is granted using the PSDataAccess database role in SQL Server. The first step is to create a SQL Server login for the account running the SQL Server Analysis Services service. Use the following procedure to create a login for the SQL Server Analysis Services service account. Note If a login already exists for the SQL Server Analysis Services service account, you can skip this procedure. To create a login for the Analysis Services service account 1. In SQL Server Management Studio, connect to the instance of the database engine where your Project Web App is located. 2. In Object Explorer, expand Security. 3. Right-click Logins, and then click New Login. 4. In the Login name box, type the name of the Active Directory account that is running the Analysis Services service. 5. Click OK. Once the login has been created, you must grant the login access to the Project Web App database. Use the following procedure to configure database access. To grant database access to the Analysis Services service account 1. In SQL Server Management Studio, connect to the database engine. 2. In Object Explorer, expand Security. 3. Double-click the login for the Analysis Services service. 4. In the Select a page section, click User Mapping. 5. Select the Map check box for the Project Web App database that you want to provide access to, and then, in the Database role membership for: section, select the PSDataAccess check box. 6. Click OK. The next step is to build an OLAP cube. Build an OLAP cube In order to configure the needed permissions in SQL Server Analysis Services, the OLAP cube must be created. Even if you do not plan to use the cube right away, you will need to build one now in order to configure the needed user access requirements. Use the following procedure to build an OLAP cube. To build an OLAP cube 1. In Central Administration, under Application Management, click Manage service applications. 2. Click the Project Server service application. 3. Hover over the instance of Project Web App for which you want to build a cube, click the arrow that appears,

165 and then click Manage. 4. On the Project Web App settings page, under Queue and Database Administration, click OLAP Database Management. 5. On the OLAP Database Management page, in the OLAP Database Name column, click the DatabaseName link. 6. On the OLAP Database Build Settings page: 7. In the Analysis Services Server box, type the name of the instance of Analysis Services where you want to build the cube. 8. In the Analysis Services Database to be created box, type a name for the OLAP database. 9. Click Save. 10. On the OLAP Database Management page, select the row in the table for the cube that you just configured, and then click Build Now. 11. Monitor the Status field on the OLAP Database Management page until the status is Build Success! After you have built the cube, you can grant users access to it. Grant access to the OLAP cube To grant users access to the cube, you must add the following groups and accounts to the default ProjectServerViewOlapDataRole role in the cube: The Report Authors Active Directory group that you created when you configured reporting for Project Web App. This group should contain the users who you expect to be working with OLAP cube data in Excel. The Secure Store Target Application account that you created when you configured reporting for Project Web App. This account will allow users viewing OLAP cube reports in Excel Services to refresh the data. If you added this account to the Report Authors group when you configured reporting for Project Web App, there's no need to add it separately here. If you have additional users beyond those in the Report Authors group who will be accessing the cube from Excel, you must grant them access to the cube as well. Consider using the same groups that you use for Active Directory synchronization to grant cube access to your users. For example, if you want all Project Managers to have access to the OLAP cube in Excel, add the Active Directory group that you're synchronizing with the Project Managers group to the ProjectServerViewOlapDataRole role in the cube. Use the following procedure to grant users access to the OLAP cube. To grant user access to the OLAP cube 1. In SQL Server Management Studio, connect to Analysis Services. 2. In Object Explorer, expand Databases. 3. Expand the cube that you just created. 4. Double-click the ProjectServerViewOlapDataRole role. 5. In the left pane, select the Membership page. 6. On the Membership page, click Add. 7. On the Select Users or Groups dialog box, click Object Types. 8. On the Object Types dialog box, select the Groups check box, and then click OK.

166 9. On the Select Users or Groups dialog box, type the name of the Report Authors Active Directory group and the name of the data access account for the ProjectServerApplication Secure Store target application. Also type the name of any additional users or groups to which you want to grant cube access. 10. Click OK. 11. Click OK. See also Active Directory Resource Pool Synchronization for Project Server 2013 Configure reporting for Project Web App (Project Server 2013) Project forums

167 Configure SQL Server and Analysis Services in Project Server /13/ min to read Edit Online Summary: Configure SQL Server and SQL Server Analysis Services (SSAS) settings prior to installing Project Server Applies to: Project Server 2013 Before you install SharePoint Server 2013 and Project Server 2013, you must first configure SQL Server and, if you're planning to use Project Server OLAP cubes, SQL Server Analysis Services. SQL Server Analysis Services must be deployed in Multidimensional mode. Note If you are installing Project Server 2013 to an existing SharePoint Server 2013 farm, some of these steps may already be completed. Complete the procedures in each section below: Configure SQL Server network settings Configure Analysis Services for building Project Server OLAP cubes Additionally, depending on the needs of your organization, you may want to do the following: Create a Project Web App database Create additional TempDB files We also recommend that you start the SQLSERVERAGENT service on the instance of SQL Server where your SharePoint Server databases are located. SharePoint Server and Project Server 2013 use the SQL Server Agent service to perform various database cleanup activities. When you have finished configuring SQL Server and Analysis Services, go to the next article, Install SharePoint Server 2013 (Project Server 2013). Configure SQL Server network settings For SharePoint Server and Project Server to work correctly, the associated instance of SQL Server must be configured to enable remote connections using TCP/IP. Use the following procedure to confirm that your instance of SQL Server is configured to allow remote TCP/IP connections. To configure SQL Server 2008 R2 or SQL Server 2012 network settings 1. Click Start, click All Programs, click Microsoft SQL Server 2008 R2 or Microsoft SQL Server 2012, click Configuration Tools, and then click SQL Server Configuration Manager. 2. In the left pane, expand SQL Server Network Configuration, and then select the instance of SQL Server where you will be installing Project Server 2013 databases. 3. In the right pane, ensure the Status for TCP/IP is Enabled.

168 Configure Analysis Services for building Project Server OLAP cubes Project Server 2013 can build OLAP cubes in SQL Server Analysis Services (SSAS) for use in reporting. If you plan to use the Project Server 2013 cube building feature, you must configure the Farm Administrator account to have administrative permissions in SQL Server Analysis Services for the instance of Analysis Services that you will be using with Project Server To add the Farm Administrator as an Analysis Services server administrator 1. Open SQL Server Management Studio. In the Connect to Server window, connect to the instance of Analysis Services that you are using with Project Server In SQL Server Management Studio, in Object Explorer, right-click your Analysis Services instance name, and then click Properties. 3. On the Analysis Services Properties page, in the Select a page pane, click Security. 4. Click Add. 5. On the Select Users, Computers, or Groups page, type the name of the Farm Administrator account. 6. Click OK. The Farm Administrator account appears in the Members list. 7. Click OK. Note For information about configuring user access for OLAP cubes, see Configure OLAP cubes for Project Web App. For information about managing OLAP databases in Project Server 2013, see OLAP database management in Project Web App. Create additional TempDB files Both Project Server 2013 and SharePoint Server 2013 make extensive use of TempDB during SQL transactions. To optimize performance, create additional TempDB files. As a rule, create an additional TempDB file for each processor (core) in the computer that is running SQL Server. Create the files on a separate partition from other database files. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears. See also Install SharePoint Server 2016 (Project Server 2016)

169 Add an application server to a farm in Project Server /13/ min to read Edit Online Summary: Add a new SharePoint Server 2013 application server with Project Server 2013 to an existing farm. Applies to: Project Server 2013 To add a Project Server 2013 application server to an existing farm, you must do the following: Install SharePoint Server 2013 prerequisites Install SharePoint Server 2013 Install Project Server 2013 Install required updates Add the server to the farm by running the SharePoint Products and Technologies Configuration Wizard Video demonstration This video shows the steps involved in adding an application server to an existing Project Server 2013 farm, as described in this article. Video: Add an application server to a Project Server farm Configure the application server Use the following procedures to configure the application server and add it to the farm. Note For these procedures, we recommend that you use the Farm Install account that you originally created to install SharePoint Server To install prerequisites for SharePoint Server On the SharePoint Server DVD, run default.hta. 2. Click Install software prerequisites. Note You must be connected to the Internet to perform this step. If you are not connected to the Internet, you must install the prerequisites manually. 3. On the Welcome page, click Next. 4. Read the license agreement, and if you accept, then select the I accept the terms of the License Agreement(s) check box.

170 5. Click Next. Note Depending on your configuration, you may be required to restart the server during this process. Once the prerequisites have been installed, the next step is to install SharePoint Server To install SharePoint Server On the SharePoint Server DVD, run default.hta. 2. Click Install SharePoint Server. 3. On the Enter your Product Key page, type your product key, and then click Continue. 4. Read the license agreement, and if you accept, then select the I accept the terms of this agreement check box, and then click Continue. 5. On the Choose the installation you want page, click Server Farm. 6. On the Server type page, click Complete. 7. If desired, select the File Location tab and change the installation location. 8. Click Install Now. 9. When installation has finished, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close. Once SharePoint Server 2013 has been installed, the next step is to install Project Server To install Project Server On the Project Server DVD, run default.hta. 2. Click Install Project Server. 3. On the Enter your Product Key page, type your product key, and then click Continue. 4. Read the license agreement, and if you accept, then select the I accept the terms of this agreement check box. 5. Click Continue. 6. On the Choose a file location page, click Install Now. 7. When installation has finished, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close. Once SharePoint Server 2013 and Project Server 2013 are installed on the computer, you must install any required updates so that the updates on the new application server match those currently on the farm. Note that this includes Project Server 2013 and SharePoint Server 2013 updates (such as service packs and cumulative updates), but does not include updates for other products, such as Windows Server or SQL Server. To add the server to the farm 1. Click Start, All Programs, Microsoft SharePoint 2013 Products, SharePoint 2013 Products Configuration Wizard. 2. On the Welcome page, click Next. 3. On the warning dialog box, click Yes.

171 4. On the Connect to a server farm page, select the Connect to an existing server farm option. 5. Click Next. 6. On the Specify Configuration Database Settings page, type the name of the instance of SQL Server where the SharePoint Server 2013 configuration database is located, and then click Retrieve Database Names. 7. Select the configuration database for the farm you want to join from the Database name drop-down box, and then click Next. 8. On the Specify Farm Security Settings page, type the farm pass phrase, and then click Next. 9. On the Completing the SharePoint Products Configuration Wizard page, click Next. 10. When the wizard has finished, click Finish. See also Project forums

172 Deploy language packs in Project Server /13/ min to read Edit Online Summary: Install and configure Project Server 2013 language packs so that users can select their preferred language for their PWA user interface. Applies to: Project Server 2013 Project Server 2013 language packs enable Project Server 2013 users to view Project Web App sites in multiple languages without requiring separate installations of Project Server You can add language support for additional languages to Project Server 2013 by installing the language pack for the language that you want to add. Language packs are typically used in multinational deployments where one server farm supports people in different locations and users want to see the Project Web App user interface displayed in their preferred language. Project Server 2013 language packs will only allow you to change the language of your Project Web App sites user interface. They do not affect the display language of project sites, or Project Web App web parts that are added to project sites. The language of project sites user interface and PWA web parts added to the project site can be changed by applying SharePoint Server 2013 language packs, which are bundled and installed with Project Server 2013 language packs. Project Server 2013 language packs do not affect the project data that is displayed in Project Web App. The project data will display in the language of the Project Server 2013 base installation, which is required to install a Project Server 2013 language pack. For example, if you apply the Project Server 2013 Japanese language pack on a base installation of Project Server 2013 English, you can display the Project Web App user interface in Japanese, but the project data on the PWA site will display in English. Language packs are not bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support. In this article: Available languages for Project Server 2013 language packs Compatibility with SharePoint Server 2013 language packs Language Pack deployment scenarios Deploy a Project Server 2013 language pack Uninstall language packs Available languages for Project Server 2013 language packs Project Server 2013 language packs are available for the following languages: LANGUAGE LL-CC LOCALE ID (LCID) NOTE Arabic ar-sa 1025 Brazilian pt-br 1046 Chinese (PRC) zh-cn 2056 Chinese (Taiwan) zh-tw 1028

173 LANGUAGE LL-CC LOCALE ID (LCID) NOTE Czech cs-cz 1029 Danish da-dk 1030 Dutch nl-nl 1043 English (US) en-us 1033 Finnish fi-fi 1035 French fr-fr 1036 German de-de 1031 Greek el-gr 1032 Hebrew he-il 1037 Hungarian hu-hu 1038 Italian it-it 1040 Japanese ja-jp 1041 Korean ko-kr 1042 Norwegian nb-no 1044 Polish pl-pl 1045 Portuguese (Brazil) pt-br 1046 Portuguese (Portugal) pt-pt 2070 Romanian ro-ro 1048 New in Project Server 2013 Russian ru-ru 1049 Slovak sk-sk 1051 New in Project Server 2010 Slovenian sl-si 1060 New in Project Server 2010 Spanish es-es 3082 Swedish sv-se 1053 Turkish tr-tr 1055 Ukrainian uk-ua 1058 New in Project Server 2010

174 Compatibility with SharePoint Server 2013 language packs Project Server 2013 language packs are bundled with SharePoint Server 2013 language packs. For example, when you download and install the SharePoint Server 2013 Spanish language pack, you also download and install the Project Server 2013 Spanish language pack. Important Project Server 2013 does not support all of the languages that SharePoint Server 2013 supports. If a Project Server 2013 language pack is not available for a language that supported in SharePoint Server 2013, the download file will only include the SharePoint Server 2013 language pack. The following languages are supported by SharePoint Server 2013, but are not available in Project Server 2013 language packs: Basque Bulgarian Catalan Croatian Estonian Galician Hindi Kazakh Latvian Lithuanian Serbian (Latin) Thai As an example, the SharePoint Server 2013 Thai language pack is not bundled with a Thai language pack for Project Server 2013, since it does not exist. For more information about SharePoint Server 2013 language packs, see Install or uninstall language packs for SharePoint Language Pack deployment scenarios The following are some deployment scenarios involving Project Server 2013 and SharePoint Server 2013 language packs. Scenario 1 The customer has a base installation of SharePoint Server 2013 (English). He wants to install Project Server 2013, but also has some users who require Project Web App in a German user interface. The customer does the following: 1. Install Project Server 2013 (English). 2. Install the Project Server 2013 German Language Pack.

175 Note The SharePoint Server 2013 German Language Pack is not required for this scenario, but is installed since it is bundled with the Project Server 2013 German Language Pack. Note For base installations of SharePoint Server 2013 and Project Server 2013, the same language must be installed. For example, if you have a base installation of SharePoint Server 2013 English, you can only install the base version of Project Server 2013 English with it. And a base installation of Project Server 2013 is required to install any Project Server 2013 language pack. Scenario 2 The customer has a base installation of SharePoint Server 2013 (Japanese) and Project Server 2013 (Japanese). She has some customers who require Project Web App in an English user interface. The customer does the following: Install the Project Server 2013 English Language Pack. Note The SharePoint Server 2013 English Language Pack is not required for this scenario, but is installed since it is bundled with the Project Server 2013 English Language Pack. Scenario 3 The customer has a base installation of SharePoint Server 2013 (Hindi). He wants to install Project Server 2013 for PWA users who require an English interface. The customer does the following: 1. Uninstall the SharePoint Server 2013 (Hindi) base installation. 2. Install SharePoint Server 2013 (English). 3. Install Project Server 2013 (English). 4. Install the SharePoint Server 2013 Hindi Language Pack. Since a Project Server 2013 (Hindi) base SKU does not exist, the customer cannot install it with the SharePoint Server 2013 (Hindi) base installation (base installation SKUs of SharePoint Server 2013 and Project Server 2013 must be in the same language). Installing the SharePoint Server 2013 (English) and Project Server 2013 (English) base SKUs allows him to make PWA available to his users who require an English user interface. Since English PWA is only required for a subset of his users, he still needs to have SharePoint Server 2013 available in Hindi. To have a Hindi SharePoint Server 2013 user interface, he can install the Hindi SharePoint Server 2013 Language Pack. Note that the Hindi SharePoint Server 2013 Language Pack will not contain a language pack for Project Server 2013, since it is not available in that language. Scenario 4 The customer has a base installation of English SharePoint Server 2013 and Project Server She requires her SharePoint Server users to have a Romanian user interface. The customer does the following: Install the Romanian SharePoint Server 2013 Language Pack.

176 Note Installing the Romanian SharePoint Server 2013 Language Pack will also install the Romanian Project Server 2013 Language Pack, which is not required for this scenario since PWA users do not require the Romanian user interface. Deploy a Project Server 2013 language pack The steps for deploying a Project Server 2013 language pack and making the language available to users are as follows: 1. Download the language pack 2. Install the language pack 3. Make the language available for the Project Web App site 4. Specify the display language for the site Important As mentioned previously, if a Project Server 2013 Language Pack is available for a specific language, it is bundled with the SharePoint Server 2013 Language Pack for that specific language. They will be downloaded as a single file and installed together to your farm. For more information about the availability of Project Server 2013 Language Packs for specific languages, see the "Available languages for Project Server 2013 language packs" section of this article. Download the language pack You must perform the following steps for each language that you want to support. If you decide to download more than one language, be aware that a unique file that has a common name is downloaded for each language. Therefore, make sure that you download each language pack to a separate folder on the hard disk so that you do not overwrite a language pack of a different language. To download the language pack 1. In your Web browser, go to Language Packs for SharePoint Server On the Language Packs for SharePoint Server 2013 page, select the language that you want from the Change Language list, and then click Change. 3. The language displayed on the site now corresponds to the language selected in the previous step. Click Download on the Web page. Note If the language on the page has not changed prior to clicking the Download command, verify that the language that you selected in step 2 is displayed in the Change Language field. 4. In the dialog box that appears, click Save to download a copy of the file to the local computer. Note If you are adding multiple language packs, you should rename the language pack file (ServerLangaugePack.exe) to a more descriptive name (for example, FrenchServerLangaugePack.exe). Because the default name for all language pack files is the same, renaming the file will help to prevent confusion when you are installing the language packs.

177 Install the language pack If you have a server farm environment and you are installing language packs to support multiple languages, you must install each language pack on all application servers and Web servers in your farm. Note Note that you are also installing the SharePoint Server 2013 language pack for the specified language during this procedure. If you are installing the Project Server 2013 language pack on a single-server farm, use the following procedure: To install a Project Server 2013 language pack for a single-server farm deployment 1. In Windows Explorer, double-click the ServerLanguagePack.exe file to start the installation. 2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue. 3. The Setup wizard runs and installs the language pack. 4. Run the SharePoint Products Configuration Wizard, using the default settings. If you are installing Project Server 2013 language packs for a multi-server farm deployment, use the following procedure: To install a Project Server 2013 language pack for a multi-server farm deployment 1. On a Web or application server in your farm, double-click the ServerLanguagePack.exe file to start the installation. 2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue. 3. The Setup wizard runs and installs the language pack. 4. The Run Configuration Wizard page appears when the language pack installation is complete. Clear the Run the SharePoint Products Configuration Wizard now check box, and then click Close. Caution Do not run the SharePoint Products Configuration Wizard at this time. 5. On each Web and application server in the farm, install the language pack by using steps 1-4. Make sure not to run the SharePoint Products Configuration Wizard after you install the language pack. Note If you are installing multiple language packs, install each one to all Web and application servers in the farm by using steps 1-5. Make sure not to run the SharePoint Products Configuration Wizard after installing the language pack. 6. After installing the Project Server 2013 language pack to all Web and application servers in the farm, return to your original server and run the SharePoint Products Configuration Wizard. Use the following steps to run the wizard: 7. Click Start, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard. 8. On the Welcome to SharePoint Products page, click Next. 9. Click Yes in the dialog box that alerts you that some services might have to be restarted during

178 configuration. 10. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next. 11. On the Configuration Successful page, click Finish. 12. Run the SharePoint Products Configuration Wizard on all Web and application servers on the farm to complete the installation. Make the language available for the Project Web App site After installing the Project Server 2013 language pack, you now have to make the language available for the site. When you make the language available, you are making the language available on a site-by-site basis. For example, making the French language available for Project Web App only allows French to be available for Project Web App sites. The language must be made available for the Business Intelligence Center or for the SharePoint Central Administration Web site for it to be possible to display the site in that language. Use the following procedure to select the language that you want to make available for the site. To select a language for the site 1. On the Project Web App site, click the Settings icon, and then click Site Settings. 2. On the Site Settings page, in the Site Administration section, click Language Settings. 3. On the Language Settings page, in the Alternate Language(s) section, click the check box next to the language that you want to make available for the site. If you have installed the Project Server 2013 language pack, the language for that language pack will be listed as an option for you to select. Note You can select multiple languages if the site has to be available in more than one language. 4. Click OK. Specify the display language for the site After you have specified the languages that are available for the site, Project Web App users can then specify the language they want to display for that site. A site user can use the following procedure to display the site user interface in an available language: To select a display language 1. On the Project Web App site page, click the user account name to display the drop-down list, and then click My Settings. 2. On the User Information page, click My Language and Region. 3. On the User Information Language and Region page, in the Language section, under the Display Languages list, click the Pick a new language menu. From the menu, select the language in which you want your Project Web App to display. Then click Add to add it to the My Display Language list. 4. In the My Display Language list, use the arrow to move the language you want your Project Web App site to display in to the top of the list. For example, if you installed the Project Server 2013 Spanish language pack on a base installation of Project Server 2013 English (United States), you will want to move Spanish (Spain) above English (United States) if you want your Project Web App site user interface to display in Spanish. 5. Click OK. Uninstall language packs

179 You can uninstall a Project Server 2013 language pack by using the Control Panel. You can uninstall a SharePoint Server 2013 language pack in the same manner. If you no longer want to make a language available for a site, clear the language from the list on the Language Settings page for the site. To remove a language for the site 1. On the Web site, click the Settings icon, and then click Site Settings. 2. On the Site Settings page, in the Site Administration section, click Language Settings. 3. On the Language Settings page, in the Alternate Language(s) section, clear the check box next to the language that you want to make unavailable for the site. 4. Click OK. See also Install or uninstall language packs for SharePoint 2013

180 Upgrade to Project Server /13/ min to read Edit Online Summary: Learn about how to upgrade to Project Server Applies to: Project Server 2016 This series of articles describes how to plan and upgrade to Project Server TechNet articles about upgrading to Project Server 2016 The following articles about upgrading to Project Server 2016 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Overview of the Project Server 2016 upgrade process Plan for upgrade to Project Server 2016 Upgrading to Project Server 2016 DESCRIPTION Provides an overview of the steps required to upgrade to Project Server Learn about things you need to consider when planning to upgrade to Project Server Learn how to upgrade to Project Server Note For information about upgrading to SharePoint Server 2016, see Upgrade to SharePoint Server 2016.

181 Overview of the Project Server 2016 upgrade process 12/13/ min to read Edit Online Summary: View a high-level overview of the steps required to upgrade to Project Server 2016 from Project Server Applies to: Project Server 2016 Note For information about planning consideration when upgrading to Project Server 2016, see Plan for upgrade to Project Server Overview of the Project Server 2016 upgrade steps Upgrading to Project Server 2016 can be broken up into six steps. These include: 1. Create the SharePoint Server 2016 farm installation and enable Project Server Project Server 2016 installs with SharePoint Server 2016 and the Project Server service application needs to be started. Important Project Server 2016 can only be enabled on the Enterprise version of SharePoint Server Project Server 2016 cannot be enabled on SharePoint Server 2016 with a Standard license. 2. Copy and move your databases from your Project Server 2013 database server to the database server that hosts your Project Server 2016 installation. These databases are: Project Server 2013 databases SharePoint 2013 content database that contains your project site collections 3. Use the Mount-SPContentDatabase PowerShell cmdlet to attach and upgrade the SharePoint 2013 content database containing your Project site data to the Project Server Use the Test-SPContentDatabase PowerShell cmdlet to check your upgraded SharePoint content databases. 5. Use the Migrate-SPProjectDatabase PowerShell cmdlet to attach and upgrade the Project Server 2013 database to the Project Server 2016 farm. 6. Use the Migrate-SPProjectResourcePlans to migrate your Project Server 2013 resource plans to resource engagements. If you don't plan to use your Project Server 2013 resource plans in Project Server 2016, this

182 step is not required. Note For detailed information about the steps required to upgrade to Project Server 2016 from Project Server 2013, see Upgrading to Project Server 2016.

183 Plan for upgrade to Project Server /13/ min to read Edit Online Summary: Learn about considerations you need to make in upgrading to Project Server Applies to: Project Server 2016 In this article: Things you need to know about upgrading to Project Server 2016 Upgrading from an earlier version of Project Server Upgrading multiple Project Web App sites Note For an overview of the steps in the upgrade process, see Overview of the Project Server 2016 upgrade process. > For details information about the upgrade process, see Upgrading to Project Server Things you need to know about upgrading to Project Server 2016 If you are planning to upgrade to Project Server 2016, it is important to know the following: You can only upgrade to Project Server 2016 through Project Server 2013 If you are upgrading from earlier versions of Project Server, you must upgrade your databases to Project Server 2013 first in order to upgrade to Project Server There is no direct upgrade path from Project Server 2010 to Project Server No in-place upgrade You must first create a Project Server 2016 installation, and then attach and upgrade your Project Server 2013 databases to the new farm. In-place upgrade is not supported. Upgrade through Windows PowerShell cmdlets Similar to the Project Server 2013 upgrade experience, upgrading to Project Server 2016 will be through the use of Windows PowerShell cmdlets. You can use the SharePoint 2016 Management Shell to run the correct version of the cmdlets used for upgrade. Upgrade your Project Server 2013 Resource Plans to Resource Engagements Resource Engagements is a new feature in Project Server 2016 that helps project managers and resource managers to align with each other on the specific amount of work and time periods for specific resources associated with a project. Resource Engagements replaces the Resource Plans feature, as they will no longer be available in Project Server You can choose to migrate your existing Project Server 2013 Resources Plans to use as Resource Engagements in Project Server 2016 as part of the upgrade process. Note that for your Project Server 2013 Resource Plans to migrate correctly to Resource Engagements, they must contain time phased data and must be published. Note For more information about Resource Engagements, see this blog post: Resource Engagements. Upgrading from an earlier version of Project Server Since upgrading to Project Server 2016 from Project Server 2013 is the only supported upgrade path, you will

184 have to upgrade to Project Server 2013 first if you are upgrading from an earlier version of Project Server. UPGRADING FROM UPGRADE PATH Project Server Upgrade to Project Server Upgrade to Project Server 2016 Project Server Upgrade to Project Server Upgrade to Project Server Upgrade to Project Server 2016 For more informations: Upgrade to Project Server 2010 Upgrade to Project Server 2013 Upgrading to Project Server 2016 Upgrading multiple Project Web App sites If you have multiple Project Web App sites using the same content database, and want the update the site collections in the content database or any of the PWA sites to 2016, all the sites in the content database and all three PWA sites must be upgraded at the same time. In the following example, Contoso is using Project Server 2013 and has three PWA sites that all use the same content database to store their data (ContentDB-A). When upgrading to Project Server 2016, the content database and all three associated Project databases need to be copied to the Project Server 2016 database server, and then attached and upgraded in the upgrade process. PWA SITE PROJECT DATABASE CONTENT DATABASE ProjectDB-A ContentDB-A ProjectDB-B ContentDB-A ProjectDB-C ContentDB-A

185 Upgrading to Project Server /13/ min to read Edit Online Summary: Learn how to upgrade to Project Server Applies to: Project Server 2016 This article describes the steps required to upgrade to Project Server Note Prior to reading this article, please see Plan for upgrade to Project Server 2016 for more information about upgrade and the upgrade process. Upgrade requirements Note the following requirements for upgrading to Project Server 2016: You can only upgrade from Project Server If you are upgrading from earlier versions of Project Server, you must upgrade your databases to Project Server 2013 first in order to upgrade to Project Server Note For information about upgrading to Project Server 2013 from Project Server 2010, see Upgrade to Project Server The upgrade process requires you to run Windows PowerShell cmdlets in the SharePoint Server 2016 Management Console. Verify that you have the required permissions to run them If you are migrating your Project Server 2013 Resource Plans to use as Resource Engagements in Project Server 2016: They must be published. They must have associated time phased data (it must contain work, not just resources). Note For more information about Resource Engagements, see this blog post: Resource Engagements. Project Server 2016 upgrade steps Upgrading to Project Server 2016 can be broken up into six steps. These include: 1. Create a Project Server 2016 farm 2. Copy and move your databases 3. Attach and upgrade your SharePoint 2013 content database 4. Test your SharePoint Content database

186 5. Attach and upgrade your Project Server 2013 databases 6. Disable database quota limits for your PWA site 7. Migrate your Project Server 2013 resource plans (optional) The following provides more detail about the upgrade steps mentioned in the upgrade overview. Create your Project Server 2016 farm The first step in the upgrade process is to create the Project Server 2016 farm. Since database attach is the supported method for upgrade, you will be attaching and upgrading your Project Server 2013 databases to this farm in the steps that follow. Note that a key difference in installing Project Server 2016 versus the way it was installed in previous versions is that the Project Server 2016 installation is now a part of the SharePoint Server 2016 installation. Project Server 2016 now runs as a service application in SharePoint Server 2016, and does not require a separate installation. Important Project Server 2016 can only be enabled on the Enterprise version of SharePoint Server Project Server 2016 cannot be enabled on SharePoint Server 2016 with a Standard license. Note For more information about how to install a new Project Server 2016 farm, see Deploy Project Server Copy and move your databases The second step in the upgrade process copies your databases required for your Project Server 2013 environment to your new Project Server 2016 environment. This is a two-step process: 1. With the SharePoint Server 2013 farm in read-only mode, the server farm administrator backs up the following two databases from the SQL Server instance: SharePoint 2013 content database that contains your project data Project Server 2013 database 2. The server farm administrator restores a backup copy of the databases to the SQL Server 2014 instance being used to host the Project Server 2016 farm databases. You can use SQL Server Management Studio to copy and the restore of the databases. Attach and upgrade your SharePoint 2013 content database The second step in the upgrade process attaches and upgrades your SharePoint 2013 content database that contains your Project site data to your new Project Server 2016 farm. You will need to run the Mount -SPContentDatabase PowerShell cmdlet in the SharePoint 2016 Management Shell in order to do this. 1. Open the SharePoint 2016 Management Shell as an Administrator. 2. At the prompt, enter: Mount-SPContentDatabase -Name <database name> -WebApplication <Web application name> For example:

187 Mount-SPContentDatabase -Name WSSContentContosoPWA -WebApplication "SharePoint 80" Test your content database The next step in the upgrade is to test your newly attached and upgraded content database. You will use the Test- SPContentDatabase PowerShell cmdlet to test against the Web application you specified to verify all customizations referenced within the content database are also installed in the web application in the new SharePoint Server 2016 environment. This cmdlet will not update your data in anyway. 1. Open the SharePoint 2016 Management Shell as an Administrator. 2. At the prompt, enter: Test-SPContentDatabase -Name <database name> -WebApplication <Web application name> For example: Test-SPContentDatabase -Name WSSContentContosoPWA -WebApplication "SharePoint 80" This will check the SharePoint - 80 Web application against the customizations referenced in the WSSContentContosoPWA database, and will post the results. The results of the Test-SPContentDatabase cmdlet will note inconsistencies it will find in your upgraded SharePoint Web application in its new SharePoint Server 2016 environment. The results do not imply that the upgrade of the SharePoint 2013 content database has failed, but will only note things you need to look into in your new environment. For example, you might see the following result: Category: MissingWebPart Error: True UpgradeBlocking : False Message: WebPart class [e6002ce8-69ee-168a-8f7c-a1d98d51da29] (class [Microsoft.Office.Excel.WebUI.ExcelWebRenderer] from assembly [Microsoft.Office.Excel.WebUI, Version= , Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [WSSContentContosoPWA], but is not installed on the current farm. Please install any feature/solution which contains this web part. Remedy: One or more web parts are referenced in the database [WSSContentContosoPWA], but are not installed on the current farm. Please install any feature or solution which contains these web parts. This message notes that the Excel Services Web Part that is referenced in the upgraded content database is not found on the SharePoint Server 2016 farm. You might need to install Office Online Server on your SharePoint Server 2016 farm for you to use it. Note Office Online Server is supported for use with Project Server Attach and upgrade your Project Server 2013 database After attaching, upgrading, and testing your SharePoint 2013 content database, the next step is to attach and upgrade your Project Server 2013 database to the Project Server 2016 farm. You will need to run the Migrate - SPProjectDatabase PowerShell cmdlet in the SharePoint 2016 Management Shell in order to do this. 1. Open the SharePoint 2016 Management Shell as an Administrator. 2. At the prompt, enter: Migrate-SPProjectDatabase -DatabaseName <database name> -SiteCollection <PWA site URL> For example:

188 Migrate-SPProjectDatabase -DatabaseName ProjectDB1 -SiteCollection " When the cmdlet completes successfully, verify that you can open the Project site you specified in Project Server Note If you have multiple PWA sites that you want to upgrade, all the sites in the content DB and all the PWA sites must be upgraded at the same time. This means that the content database containing the project site data as well as any associated Project databases for each PWA site must be upgraded. Disable database quota limits for your PWA site You will need to run the following Windows PowerShell cmdlet to disable a database quota limit restriction that is set by default in Project Server 2016: Set-SPProjectDatabaseQuota -URL < -Enabled:$false -ReadOnlyLimit ReadOnlyWarningThreshold 90 - MaxDbSize For example: Set-SPProjectDatabaseQuota -URL -Enabled:$false -ReadOnlyLimit ReadOnlyWarningThreshold 90 -MaxDbSize Note If the database quota limit restriction is not disabled, you will run into the following issues:> If you are upgrading to Project Server 2016 and your Project database you are upgrading is larger than 10 Gigs, your PWA site will immediately be set to Read-Only.> If you deploy Project Server 2016, configure a PWA site, and through daily product use, the data for the site eventually goes over the 10 Gig limit, your PWA site will be set to Read-Only.> If you are using multiple PWA sites, the cmdlet must be run for each PWA site. Note For more information about this issue, see Project Support Blog: If your PWA site goes read-only Upgrade your Resource Plans to Resource Engagements If you want to use the Resource Engagements feature in Project Server 2016, you can choose to upgrade your existing Project Server 2013 Resource Plans for use as Resource Engagements. To do this, after upgrading your Project Server 2013 database to Project Server 2016, you will also need to run the Migrate- SPProjectResourcePlans PowerShell cmdlet in the SharePoint 2016 Management Shell. 1. Open the SharePoint 2016 Management Shell as an Administrator. 2. At the prompt, enter: Migrate-SPProjectResourcePlans -URL <PWA site URL> For example: Migrate-SPProjectResourcePlans -URL " After running the cmdlet, you should receive one of the following confirmation messages:

189 MESSAGE All Project Resource Plans successfully migrated Migrated {0} of {1} Project Resource Plans. Check the logs for more details. There are no more project resource plans to migrate. Either all resource plans were migrated or exceeded the maximum retry count. Please check table MSP_RESOURCE_PLANS in the published store and verify RESPLAN_IS_MIGRATED is set for all projects WHAT THIS MEANS All resource plans were found and all were migrated Resource plans were found but some fail to migrate. No resource plans were found to migrate or the maximum number of attempts have passed. If your resource plans did not migrate successfully (you received either of the last two messages), you can use the following troubleshooting steps to find more information. Check your SharePoint Server 2016 content database for resource plan migration information Check the MSP_RESOURCE_PLANS table for the following columns: COLUMN RESPLAN_IS_MIGRATED MIGRATED_REV_COUNTER MIGRATION_ERROR_INFO VALUES "0" not migrated "1" migrated The value shown is the number of attempts it took to migrate this resource plan. If the command is run repeatedly, this value is incremented each time, with a maximum value of 50. Provides additional information about migration: MissingResources=1, followed by a list of missing resources AccessDenied=2, followed by any additional information DatabaseError=3, followed by any additional information Unknown=4, followed by any additional information Check your SharePoint Server 2016 content database for resource plan migration information You can check to see if a specific PWA site you are migrating has an associated resource plan. You use the following SQL query to do this: SELECT * FROM [DBName].[pjpub].[MSP_RESOURCE_PLANS] where SiteId = <SiteId> There is a row in this table for each resource plan for the site (A project can have 0 or 1 resource plan). To get the SiteID value for your PWA site, run the following PowerShell cmdlet in the SharePoint Server 2016 Management Console: $site = get-spsite <SiteUrl> $site.id Check your ULS logs for more information The following tags in category:engagements (PWA) may have useful information to help troubleshoot any problems associated with your resource plan migration: tag_a5h65 tag_a5h66

190 tag_a1kg8 tag_a3qj3 tag_a1khb tag_a5h67 tag_a1khf tag_a2ifm tag_a4bic tag_a1khh tag_a2ifo

191 Upgrade to Project Server /13/ min to read Edit Online Summary: Learn about how to upgrade to Project Server Applies to: Project Server 2013 This series of articles describes the steps necessary upgrade to Project Server This includes planning and preparing for upgrade, moving copies of your databases to your Project Server 2013 destination environment, and upgrading your Project Server 2010 data and PWA site data. TechNet articles about upgrading to Project Server 2013 CONTENT What's new for upgrade (Project Server 2013) Overview of the Project Server 2013 upgrade process Plan for upgrade to Project Server 2013 Prepare your environment for upgrade (Project Server 2013) Create backup copies of your Project Server 2010 farm databases for upgrade (Project Server 2013) Restore your Project Server 2010 farm databases for upgrade (Project Server 2013) Upgrade your databases and Project Web App site collections to Project Server 2013 Post-upgrade tasks: Address known issue with Enterprise Project Types (Project Server 2013) DESCRIPTION Learn about key changes and considerations when you upgrade to Project Server Before you plan to upgrade to Project Server 2013, you must have an understanding of the general steps required to upgrade. When you upgrade to Project Server 2013, things to consider include system requirements and your current environment. After you create a plan to upgrade your environment to Project Server 2013, you must prepare you environment before you can start the actual upgrade process. Describes how to create backup copies of your Project Server 2010 farm database in order to upgrade to Project Server Describes how to restore your Project Server 2010 databases to the SQL Server instance that is hosting your Project Server 2013 data. Describes how to upgrade your required Project Server 2010 databases and your Project Web App site collection to Project Server Describes how to address a known issue with Enterprise Project Types after you upgrade to Project Server 2013.

192 Note For information about upgrading to SharePoint Server 2013, see Get started with upgrade to SharePoint 2013 Products.

193 What's new in Project Server 2013 upgrade 12/13/ min to read Edit Online Summary: Learn about key changes and considerations when you upgrade to Project Server Applies to: Project Server 2013 Upgrading to Project Server 2013 differs in many ways from upgrading to previous versions of Project Server. When you upgrade to Project Server 2013, it is important to consider the following: Database-attach is the supported method for upgrading to Project Server 2013 Upgrade from Project Server 2010 to Project Server 2013 includes database consolidation to a single database Upgrade from Office Project Server 2007 to Project Server 2013 involves two major steps Client compatibility with Project Server 2013 Upgrade from Project Server 2010 to Project Online Known issues when you upgrade to Project Server 2013 Database-attach is the supported method for upgrading to Project Server 2013 When you upgrade to Project Server 2013, database-attach upgrade is the only supported method. Database-attach upgrade lets you attach your required databases to your Project Server 2013 farm, and then upgrade the databases. Database-attach upgrade requires you to install a "destination environment" a Project Server 2013 farm. Note In-place upgrade (where the Project Server binary files are upgraded on the same hardware) is not a supported method for upgrading to Project Server When you upgrade to Project Server 2013, you are required to use the following databases from your Project Server 2010 environment: Project Server 2010 Archive Project Server 2010 Draft Project Server 2010 Published Project Server 2010 Reporting SharePoint Content database containing the Project Web App site data

194 Important When you upgrade to Project Server 2013, full database-attach upgrade (sometimes referred to as "five database-attach") is used. This means that the SharePoint Content database that contains the Project Web App site data, and the Project Server 2010 databases, is required for upgrade. The SharePoint Content database must be used, or else project details pages and workflows will not function. Also, all project workspaces will not be available, along with associated documents, lists, risks, issues, and deliverables. Upgrade from Project Server 2010 to Project Server 2013 includes database consolidation to a single database Project Server 2013 architecture has been improved to reduce total cost of ownership (TCO) for database maintenance. In Project Server 2010 and Office Project Server 2007, each PWA instance hosted a majority of its project data on the four Project Server databases (Draft, Publish, Reporting, and Archive). When you upgrade to Project Server 2013, your four Project Server 2010 databases are merged into a single Project Web App database (default name: ProjectWebApp). The reduction in the number of databases required to run Project Server 2013 equates to a reduction in the costs to maintain, update, back up, and plan for disaster recovery for your Project Server 2013 data. Note For information about recommended hardware requirements for your database tier in Project Server 2013, see Hardware and software requirements for Project Server Upgrade from Office Project Server 2007 to Project Server 2013 involves two major steps There is no direct upgrade path from Office Project Server 2007 to Project Server When you upgrade from Office Project Server 2007, you must first upgrade to Project Server 2010, then upgrade the required databases to Project Server For information about how to upgrade from Office Project Server 2007 to Project Server 2010, see the following resources: Upgrade and Migration for Project Server 2010 TechNet Resource Center: This site contains links to all Project Server 2010 upgrade technical content on Microsoft TechNet. Microsoft Project Server 2010 Upgrade SuperFlow: An interactive Help file that you can download and install on your local computer. It contains the Project Server 2010 TechNet upgrade content set, made viewable to the user through logically organized category tabs and sequential data flow objects. Client compatibility with Project Server 2013 Note the following in regards to Project Professional and Project Web App client compatibility to Project Server 2013: Project Server 2013 will only accept connections from Project Professional Project Web App users in Project Server 2013 will be able to use the all browsers that are supported for use with SharePoint Server These include the following: Internet Explorer 10

195 Internet Explorer 9 Internet Explorer 8 FireFox 10 Mac Safari 5 Google Chrome 17 Note For more information about client connectivity, see Plan for upgrade to Project Server Upgrade from Project Server 2010 to Project Online The release of Project Server 2013 is also paired with the release of a new service in Office 365 for enterprises, Project Online. With Project Online in Office 365, all operational maintenance is handled through an online service that is hosted in Microsoft datacenters. Project Online in Office 365 delivers full Project Portfolio Management (PPM) capabilities (Demand Management, Portfolio Management, Resource Management, Reporting, and so on). Portfolio managers, project managers, and team members can access Project Online from anywhere with an Internet connection. Project Server 2010 customers may want to upgrade from their on-premises environment to Project Online in Office 365. Upgrading your on-premises environment to Project Online in Office 365 is done through 3rd party tools. For more information about available 3rd party tools, see the MSDN blog post Want to test-drive Project Online? How to migrate data from on-premises to Online. Known issues when you upgrade to Project Server 2013 The following are current known issues that occur when you upgrade to Project Server 2013: Upon completing the upgrade from Project Server 2010 to Project Server 2013, if you click New in the PWA ribbon, you only see the Basic Project Plan Enterprise Project Type (EPT). You do not see other project types that are available in Project Server The workaround for this issue is to manually add the Project Server 2013 EPTs. For more information about this workaround, seepost-upgrade tasks: Address known issue with Enterprise Project Types (Project Server 2013). When you upgrade your Project Server 2010 databases to Project Server 2013, your Project Server 2010 databases must be in native mode (not backward compatibility mode). If your Project Server 2010 databases are in backward compatibility mode (BCM) when you upgrade, you may experience some issues (such as missing pages) with your sites after upgrade, because BCM is not a supported feature in Project Server For more information about this issue, see Prepare your environment for an upgrade to Project Server 2013 Note For more information about backward compatibility mode, see Project Server 2010 backward compatibility mode. If your Project Server 2010 Published database contains resource accounts in which the WRES_Account field contains an empty string (expected value is NULL), upgrade of this database will fail. We recommend that you check for this condition before attempting an upgrade, especially if you had upgraded resource accounts from Office Project Server 2007 to Project Server 2010 in the past. If your upgrade to Project Server 2013 fails because of this condition, you cannot use the same copies of your Project Server 2010 databases to fix the issue and retry upgrade. You must restore the original Project Server 2010 databases to the SQL Server,

196 fix the condition, and then retry the upgrade. To check for this condition, run the following SQL script on the backup copy of your Project Server 2010 Published database: Use ProjectServer_Published select RES_Name, RES_TYPE, RES_ID from MSP_RESOURCES where WRES_ACCOUNT ='' If accounts with this condition are found, run the following SQL script on the same database to fix the accounts: Use ProjectServer_Published Update MSP_RESOURCES set WRES_ACCOUNT = null where WRES_ACCOUNT ='' Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears. See also Plan for upgrade to Project Server 2013 Overview of the Project Server 2013 upgrade process Prepare your environment for upgrade for an upgrade to Project Server 2013

197 Overview of the upgrade process to Project Server /13/ min to read Edit Online Summary: Upgrade from Project Server 2010 to Project Server Applies to: Project Server 2013 This article contains an overview of the procedures required to upgrade to Project Server 2013 from Project Server Note If you are upgrading to Project Server 2013 from Office Project Server 2007, you must first upgrade to Project Server There is no direct upgrade path from Office Project Server 2007 to Project Server For more information, see What's new for upgrade (Project Server 2013). Upgrade process overview Upgrading to Project Server 2013 from Project Server 2010 can be separated into the following sequential phases: 1. Create the Project Server 2013 farm 2. Copy the required databases from the Project Server 2010 farm 3. Restore the databases to the computer that is running SQL Server that is hosting your Project Server 2013 databases 4. Upgrade the databases 5. Upgrade the Project Web App site collection Create the Project Server 2013 farm The first stage in upgrading to Project Server 2013 is to create the new Project Server 2013 destination farm. 1. The server farm administrator installs SharePoint Server 2013 to a new farm. Note SharePoint Server 2013 is a prerequisite for installing Project Server The server farm administrator installs Project Server 2013 to the farm. Copy the required databases from the Project Server 2013 farm 1. The farm administrator sets the Project Web App (PWA) site collection in the Project Server 2010 farm to read-only so that users can continue to access the old farm while the upgrade is in progress on the new farm. This ensures that no jobs are processed during the upgrade process. 2. With the PWA site collection set to read-only mode on the Project Server 2010 farm, the database administrator creates backup copies of the databases required for upgrade. These include the following: Project Server 2010 Archive

198 Project Server 2010 Draft Project Server 2010 Published Project Server 2010 Reporting SharePoint content database that contains the Project Web App site data Note For more information about copying your Project Server 2010 farm databases for upgrade, see Create backup copies of your Project Server 2010 farm databases for upgrade to Project Server Restore the databases to the computer that is running SQL Server that is hosting your Project Server 2013 farm databases The farm administrator restores the Project Server 2010 databases to the computer that is running SQL Server that is hosting your Project Server 2013 farm databases. Note For more information about restoring your databases, see Restore your Project Server 2010 farm databases for upgrade (Project Server 2013). Upgrade the databases 1. The server farm administrator attaches and upgrades the SharePoint Content database to the Project Server 2013 farm. 2. The server farm administrator consolidates the four Project Server 2010 database to a single Project Services database. 3. The new Project Services database is attached and then upgraded to the Project Server 2013 farm. Upgrade the Project Web App site collection 1. The farm administrator tests and then upgrades the Project Web App (PWA) site collection. 2. The farm administrator enables PWA features for the site. Note For detailed procedures about upgrading your databases and the PWA site collection, see Upgrade your databases and Project Web App site collections to Project Server Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears.

199 See also Plan for upgrade to Project Server 2016 What's new for upgrade (Project Server 2013) Prepare your environment for upgrade (Project Server 2013) Plan for upgrade (SharePoint 2013 Products)

200 Plan for upgrade to Project Server /13/ min to read Edit Online Summary: When you upgrade to Project Server 2013, primary things to consider include system requirements and your current environment. Applies to: Project Server 2013 When you plan to upgrade to Project Server 2013 from a previous version of Project Server, it is important to consider the following planning areas that are key in ensuring a successful upgrade of your environment: Review system requirements for upgrade to Project Server 2013 Plan for clients Gather information about your current environment Plan for upgrading customizations Create an upgrade communications plan Review system requirements for upgrade to Project Server 2013 When you plan for upgrade, it is important to plan for the following system requirements: Upgrading to Project Server 2013 does not support an in-place upgrade option (where the Project Server files are upgraded on the same hardware) Project Server 2013 will need to be installed in its own environment, to which your Project Server 2010 databases and the SharePoint content database containing your Project Web App site data will be upgraded. You will need to plan for additional hardware and software for the Project Server 2013 "destination environment." Review your Project Server 2013 hardware and software requirements As noted above, upgrading to Project Server 2013 is only through the database attach method, which requires to you install a Project Server 2013 "destination environment." You should review the Project Server 2013 hardware and software requirements to plan for deploying your Project Server 2013 environment. For more information about Project Server 2013 hardware and software requirements, seehardware and software requirements for Project Server Note Verify that you are installing SharePoint Server 2013 and Project Server 2013 on a clean server farm instance that has not previously hosted SharePoint Server Uninstalling SharePoint Server 2010 does not completely remove all installed files, folders, registry entries and other components. Installing SharePoint Server 2013 and Project Server 2013 on such a server will likely cause issues. It is recommended that you reformat the hard drive and reinstall Windows Server if you do chose to use such a server. Prepare to upgrade your Project Professional client users for the upgrade to Project Server 2013 Project Server 2013 supports client connectivity from Project Professional 2016 and Project Professional Your Project Professional 2010 users will not be able to connect to Project Server Project Server 2013 does not provide a backward compatibility feature that allows Project Professional 2010 users to connect. To see Project Professional 2013 installation requirements, see the "Plan for clients" section of this article.

201 Plan for clients When you plan to upgrade to Project Server 2013, you must take into account that you may also need to upgrade your clients that you plan on connecting to Project Server Clients who are connecting through Project Professional or Project Web App may no longer be able to connect with their existing client software or web browser after upgrading to Project Server The following client connectivity table describes which versions of Project Professional and Web browsers for Project Web App are supported for use with different versions of Project Server: PROJECT SERVER VERSION SUPPORTED PROJECT PROFESSIONAL VERSIONS SUPPORTED WEB BROWSERS FOR PROJECT WEB APP Project Server 2013 Project Professional 2013 Project Professional 2016 Project Online Desktop Client Project Server 2010 Project Professional 2010 Project Professional 2007 with Service Pack 2 (only when Backward Compatibility Mode is enabled on Project Server 2010) Internet Explorer 11 Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 Mozilla FireFox (latest released version) Apple Safari (latest released version) Google Chrome (latest released version) > [!NOTE]> Project Server 2013 Project Web App supports the same web browsers that SharePoint Server 2013 does. Internet Explorer 11 Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 Internet Explorer 7 > [!NOTE]> Project Server 2010 Service Pack 1 provides support for the following web browsers for certain team member pages:> Mozilla FireFox 3.6.8> Google Chrome 6.0 on Windows 7> Apple Safari 5 on Mac OS X v10.6> For more information, seeplan browser support (Project Server 2010). Project Server 2007 Project Professional 2007 Internet Explorer 9 Internet Explorer 8 Internet Explorer 7 Internet Explorer 6 Project Professional requirements Project Server 2013 only accepts connections from Project Professional 2016 and Project Professional You must upgrade your Project Professional 2010 clients in order to connect to Project Server The following table shows you the versions of Project Professional that are supported for use with Project Server 2013, Project Server 2010, and Office Project Server PROJECT SERVER VERSION SUPPORTED CLIENT VERSION NOTE Project Server 2013 Project Professional 2013 Project Professional 2016 Project Online Desktop Client

202 PROJECT SERVER VERSION SUPPORTED CLIENT VERSION NOTE Project Server 2010 Project Professional 2010 Project Professional 2007 with Service Pack 2 (only in backward compatibility mode) Will only accept connections from Project Professional 2007 with Service Pack 2 when backward compatibility mode is enabled in Project Server Important Project Server 2013 does not have a backward compatibility feature that enables earlier versions of Project Professional to connect to the server. Project Professional 2013 has the following installation requirements: Project Professional 2013 Installation requirements Computer and processor Memory 1 GHz or faster x86/x64 processor with SSE2 instruction set 1 GB RAM (32-bit) 2 GB RAM (64-bit) Operating system Windows 7 Windows 8 Windows 2008 R2 > [!NOTE]> Requires.NET 3.5 Framework or greater Graphics Graphics hardware acceleration requires a DirectX10 graphics card 1024x576 resolution Browser Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 FireFox 10 Mac Safari 5 Google Chrome 17 Visual reports Excel 2007, Excel 2010, or Excel 2013 Microsoft Office Visio 2007, Visio 2010, or Visio 2013 Note For more information about Project Professional 2013 and other Office 2013 client installation requirements, see System requirements for Office Supported browsers for Project Web App The following web browsers are supported for using Project Web App: Internet Explorer 10 Internet Explorer 9 Internet Explorer 8 FireFox 10

203 Mac Safari 5 Google Chrome 17 Important The web browsers in this list are the same that are supported for SharePoint Server Gather information about your Project Server 2010 environment You should gather current configuration information about your Project Server 2010 environment so that you can recreate it on your new system (the Project Server 2013 destination environment). This can include the following: Alternate access mappings Authentication providers and authentication modes in use Quota templates Customizations Managed Paths Self-service site management settings Incoming and out-going settings Plan to upgrade customizations Before you upgrade, you must identify and then evaluate the customizations in your Project Server 2010 environment and determine whether you will upgrade them, and how. After you upgrade to your Project Server 2013 test environment, check to see if the customizations you want to migrate can be reapplied. Note For detailed information about how to plan for upgrading customizations, see Create plan to upgrade customizations (SharePoint 2013). During the upgrade process, several Microsoft PowerShell "test" cmdlets can be run on your databases to verify if specific customizations in your Project Server 2010 environment can cause issues with the upgrade process. In most cases, customizations will not cause the actual upgrade process to fail. Note For more information about Microsoft PowerShell "test" cmdlets and other cmdlets used in the upgrade process, see Upgrading to Project Server Create an upgrade communications plan It is important that you communicate with users during the upgrade process to Project Server Project Web App users need to know what to expect when they visit the site again after upgrade, and Project Server client (Project Web App and Project Professional) users need to know how they can help prepare for upgrade and what they will have to do after upgrade. All users who access Project Server need to know when the upgrade will occur. As part of the planning process, determine the following:

204 Who are the members of the upgrade team, what other stakeholders are involved, and who will be affected by the upgrade What information must the upgrade team have, and when What information must users and other stakeholders have, and when Create an upgrade team For small deployments, the upgrade team might consist of only one person. For larger deployments, on the other hand, several people with different roles can be required, as described in the following list: Server administrators The server administrator performs most of the upgrade tasks. There must be at least one server administrator on the upgrade team because running the Setup wizard requires someone who is a member of the local Administrators group on each front-end Web server. Note Farm administrators might not be local administrators for the server. Project Server administrators Project Server administrators are trained to use the various Project Web App configuration and control features. They are responsible for modifying and maintaining general settings of the EPM application such as enterprise global codes, Project Web App views, Project Professional global settings, and so on. SharePoint Server administrator It is essential to get assistance from a SharePoint administrator. A SharePoint administrator can help you upgrade the SharePoint content database with your Project site data, deal with SharePoint customizations, and make sure that SharePoint Server 2013 is installed and configured properly in your "destination" environment. Many Project Server 2013 features are closely tied with SharePoint Server 2013 (such as My tasks and reporting), and it is important that a SharePoint Server 2013 expert is available after upgrade to test the environment to ensure the upgraded data can accessed and used in it. Database administrators If you have a separate database administration team, you must coordinate with it to schedule the upgrade and perform the upgrade. Server security teams You must coordinate with your security teams, such as the Active Directory directory services team, to verify accounts and permissions or to take advantage of the new policy settings that you can apply for Project Server Client deployment team Communicate with client deployment teams to coordinate deployments of the new Project Professional client and server applications. The client deployment team also has to verify that all Project Web App users support the new browser requirements (Internet Explorer 7.0 or newer). Backwards compatibility mode (BCM) allows you some flexibility in scheduling your Project Professional client upgrade. This team should also contain a representative for the Project Management Office (PMO). Developer staff If you have custom templates, Web Parts, Web services, or other custom elements associated with your Project Web App sites, you must work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements or verify that these elements have been upgraded correctly. You must also ensure that custom applications developed to work with Project Server are still functional. This is especially true when you are doing a database-attach upgrade where many of the customizations will have to be redeployed manually to the new environment.. Project Server users This group can include general Project Web App users, team members, Project Managers, Timesheet managers, and all other people who access data in Project Server. You must communicate to both Project Professional and Project Web App users about when the upgrade will occur

205 and what they should expect with regard to changes. If you have existing Project Professional 2010 users, you must work with them to upgrade to Project Professional 2013, since backward compatibility mode is not available for clients who connect to Project Server Prior to the upgrade process, you must inform users of tasks that they should do to ensure that the project data that they work with is in an upgradeable state. Communicating pre-upgrade tasks to end-users (for example, "ensure that all projects are checked in") helps prevent problems during the upgrade. Network engineers Network engineers must work with server administrator to do tasks such as creating new DNS entries, and so on. Sponsors and other stakeholders You might have other people in your organization involved in the upgrade planning process. Make sure that you include them in your communication plan appropriately. Note An upgrade team can include one or more members in each role, depending on your organization. What and when to communicate to the upgrade team In general, the farm administrators and service application administrators set the timeline for upgrade, and site owners are notified only when the process is about to begin. However, because team members have their own tasks to perform at particular points in the overall upgrade process, make sure that you have a solid plan to communicate the progress of the upgrade to all team members so that everyone knows when it is time to perform their particular tasks. The whole upgrade team must work together to determine the following: Dates and times to perform the upgrade We recommend that you upgrade when site usage is low. For small single-server deployments, upgrade may be completed in less than a day. For larger deployments, such as server farms with large amounts of data, it can take much longer. There is no way to determine the precise length of time that will be required to upgrade. Because of this, it is very important to communicate with other team members involved in the upgrade process in addition to end-users. The day or days that you choose for upgrading should be far enough in the future that the upgrade team has enough time to complete all of the preliminary steps. When you plan the timeline, make sure that you schedule time to validate the upgraded Project Web App site and project data and also schedule time to implement any changes. Also note that you may need to upgrade Project Server client to access Project Server This can include upgrading Project Professional and Internet Explorer 6.0 users. For more information, see the Plan for Clients section of this article. The upgrade approach to use It is important to communicate with site owners, designers, and developers at the following points during the upgrade process: Before the process starts, so that they know the general timeline and what their roles in the process will be. After the upgrade, so that they can validate their upgraded data and the Project Web App site, and can make any changes that are needed. What and when to communicate to users It is equally important to communicate with the Project Server users about the following issues: When their sites will be upgraded Users must be informed that they will be unable to access data during the upgrade (for example, over the weekend). You must also inform users to leave the data in a state that is ready for migration. (For example, all projects should be checked in, and pending timesheet and status updates should be approved or denied.) This helps eliminate problems that might occur during the upgrade.

206 When to expect Project Server 2013 to be ready to access "Ready to access" means that the upgrade team has not only upgraded but also verified the functionality after the upgrade. You must also prepare information that is required for users to connect to the upgraded version such as a new URL for the Project Web App site. How the upgrade might affect them and what they should know about the new environment For example, the Project Web App site will look different and function slightly differently in the new user interface. You can prepare training materials, such as quick reference sheets, to prepare users for any changes that might have occurred in the processes they do in Project Server. You can also point them to available content, such as "What's New" articles, to learn about the new version. How to get help If users find an issue with the data after the upgrade, where can they go for information or help? Microsoft Gold Certified Partners Microsoft has certified several partner companies as experts for EPM deployments and system migrations. You can find partners on the Microsoft Web site by searching for EPM solution providers at Microsoft Solution Marketplace ( Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears. See also Overview of the Project Server 2013 upgrade process Prepare your environment for upgrade (Project Server 2013)

207 Prepare your environment for an upgrade to Project Server /13/ min to read Edit Online Summary: After you create a plan to upgrade your environment to Project Server 2013, you must prepare you environment before you can start the actual upgrade process. Applies to: Project Server 2013 This article describes these tasks that must be done prior to upgrading from your current Project Server environment. Prior to upgrading your Project Server 2010 data to Project Server 2013, you must prepare your upgrade environment by doing the following: Deploy your Project Server 2013 destination environment Prepare your Windows PowerShell environment Disable backward compatibility mode in your Project Server 2010 environment Check your Project Server 2010 data for issues that can cause the upgrade to fail Deploy your Project Server 2013 destination environment Because in-place upgrade is not supported for upgrading to Project Server 2013, the database-attach upgrade method requires you to install Project Server 2013 so that you have an environment to which you can migrate your Project Server 2010 data. For a Project Server 2013 installation, the minimum operating system supported is the 64-bit version of Windows Server 2008 R2 Service Pack 1 (SP1). The minimum SQL Server version supported is the 64-bit version of SQL Server 2008 R2 with Service Pack 1 (SP1). For additional Project Server 2013 system requirements for installation, see Hardware and software requirements for Project Server For information about installing Project Server 2013, see Deploy Project Server Note We recommend that you first upgrade the Project Server 2010 data to a Project Server 2013 test environment before you attempt to upgrade to your production environment. Prepare your Windows PowerShell environment You use Microsoft PowerShell commands to execute many of the procedures required to upgrade to Project Server On the computer on which you installed Project Server 2013, it is important to verify that you have the ability to open the SharePoint 2016 Management Shell, and that you are able to access the PowerShell cmdlets for Project Server To open the SharePoint 2013 Management Shell and verify that you can access the Project Server 2013 cmdlets 1. Click Start, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell. This opens the SharePoint 2013 Management Shell.

208 2. In the SharePoint 2013 Management Shell, enter the following at the PS> prompt, and then press Enter: Get-Command *SPProject* This command provides a list of Project Server 2013 cmdlets that you are able to run. If you do not see any of the Project Server 2013 cmdlets in the results, verify that you had launched the SharePoint 2016 Management Shell and that Project Server 2013 has been installed. If you just installed Project Server 2013, close and reopen your SharePoint 2016 Management Shell and try this procedure again. Disable backward compatibility mode in your Project Server 2010 environment When you upgrade your Project Server 2010 databases to Project Server 2013, your Project Server 2010 databases must be in native mode (not backward compatibility mode). If your Project Server 2010 databases are in backward compatibility mode (BCM) when you upgrade, you may experience some issues with your sites after upgrade (for example, missing pages), because BCM is not a supported feature in Project Server Also, if you turn off BCM in Project Server 2010 in order to meet this upgrade requirement, you must also check-out, open and save the Enterprise Global Template file in Project Professional 2010, and then check the file back in. After these requirements are met, you can then create backup copies of the Project Server 2010 databases in order to upgrade to Project Server Once you disable BCM in the Project Server 2010 environment, BCM cannot be re-enabled. If you do not want to switch the Project Server 2010 farm to native mode, you can create an intermediate Project Server 2010 farm on which to restore the original Project Server 2010 databases. You can then switch from BCM to native mode on the intermediate farm, and then use these databases to upgrade to Project Server Important It is critical that you check-out, open, save, and check-in the Enterprise Global Template file in Project Professional 2010 after you disable BCM. If this is not done, new projects created in your upgraded environment may be corrupted. Note For more information about backward compatibility mode, see Project Server 2010 backward compatibility mode (BCM). Check your Project Server 2010 data for issues that can cause the upgrade to fail The following are current known issues that occur when upgrading to Project Server 2013: Upon completing the upgrade from Project Server 2010 to Project Server 2013, if you click New in the Project Web App ribbon, you only see the Basic Project Plan and the Sample Proposal. You do not see other project types that are available in Project Server After upgrading to Project Server 2013, you can correct this known issue with a simple workaround that is described inpost-upgrade tasks (Project Server 2013). In Project Server 2010, the Prevent Active Directory synchronization for this user option is available for each user in the user's property page. Selecting this option will allow you to manually specify the security group membership for the user and prevent the user's memberships from being altered when synchronizing security groups with Active Directory. When upgrading from Project Server 2010 to Project Server 2013, this option is no longer available.

209 The Prevent Active Directory synchronization for this user option is not available in Project Server 2013 due to improvements in Active Directory synchronization. When a Project Server 2010 user is migrated to Project Server 2013 during upgrade with this option enabled, the very first security group synchronization will remove them from any Project Server security groups that they are not a member of in Active Directory. Before upgrading to Project Server 2013 from Project Server 2010, verify that the Prevent Active Directory synchronization for this user option is disabled for all users. You can determine which Project Server 2010 users have the Prevent Active Directory synchronization for this user option enabled through the Project Server 2010 Publish database. You can use the following code: Use ProjectServer_Published select RES_NAME, WRES_ACCOUNT, WRES_ from MSP_RESOURCES where RES_PREVENT_ADSYNC = 1 In order for these users to maintain their membership to their security groups in Project Server 2013, you must insure they are added to the Active Directory groups that are configured to synchronize with the Project Server security groups to which they belong. If your Project Server 2010 Published database contains resource accounts in which the WRES_Account field contains an empty string (the expected value is NULL), upgrade of this database will fail. To check for this condition, run the following SQL script on the backup copy of your Project Server 2010 Published database: Use ProjectServer_Published select RES_Name, RES_TYPE, RES_ID from MSP_RESOURCES where WRES_ACCOUNT ='' If accounts with this condition are found, run the following SQL script on the same database to fix up any accounts with this condition: Use ProjectServer_Published Update MSP_RESOURCES set WRES_ACCOUNT = null where WRES_ACCOUNT ='' Note We recommend that you check for this condition before attempting an upgrade, especially if you have upgraded resource accounts from Office Project Server 2007 to Project Server 2010 in the past. If your upgrade to Project Server 2013 fails because of this condition, you cannot use the same copies of your Project Server 2010 databases to fix the issue and retry upgrade. You must restore the original Project Server 2010 databases to the computer that is running SQL Server, fix the condition, and then retry the upgrade. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears.

210 See also Plan for upgrade to Project Server 2013 Overview of the Project Server 2013 upgrade process Plan for upgrade (SharePoint 2013 Products) Create a communication plan (SharePoint 2013)

211 Create backup copies of your Project Server 2010 farm databases for upgrade to Project Server /13/ min to read Edit Online Summary: Learn how to back up Project Server 2010 databases by using SQL Server 2005, SQL Server 2008 or SQL Server 2008 R2, or SQL Server Applies to: Project Server 2013 Upgrading to Project Server 2013 requires you to use the database-attach upgrade method. This method upgrades your Project Server 2010 databases and merges them in a single Project Web App database. It also restores the Project Web App content database to your Project Server 2013 farm. One of the first steps in upgrading from Project Server 2010 to Project Server 2013 is to create backup copies of your databases that you will need to upgrade from your Project Server 2010 farm deployment. These databases include the following: Project Server Draft Project Server Archived Project Server Published Project Server Reporting SharePoint content database (which contains your Project Web App site data) The following sections describe how to create backup copies of these databases in SQL Server. These include procedures in each of the SQL Server versions that are supported for use with Project Server 2010: SQL Server 2005 SQL Server 2008 or SQL Server 2008 R2 SQL Server 2012 After you complete this procedure, you will have to restore your backup copies of your databases to the SQL Server instance that you are using to host your Project Server 2013 databases. For more information, see Restore your Project Server 2010 farm databases for upgrade (Project Server 2013). Create backup copies of your databases in SQL Server 2005 To back up a database in SQL Server On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, fill in the connection information, and then click Connect. 3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name. 4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears. 5. In the Source section, in the Database box, verify the database name. 6. In the Backup type box, select Full.

212 7. For the Backup component, select Database. 8. In the Backup set section, in the Name box, either accept the default backup set name that is suggested or type a different name for the backup set. 9. In the Destination section, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add. 10. Click OK to start the backup process. Repeat the previous procedure to back up the remaining required databases. Create backup copies of your databases in SQL Server 2008 and SQL Server 2008 R2 To back up a database in SQL Server 2008 or SQL Server 2008 R2 1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, fill in the connection information, and then click Connect. 3. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name. 4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears. 5. In the Source area, in the Database box, verify the database name. 6. In the Backup type box, select Full. 7. Under Backup component, select Database. 8. In the Backup set section, in the Name box, either accept the default backup set name or type a new name. 9. In the Destination section, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add. 10. Click OK to start the backup process. Repeat the previous procedure to back up the remaining required databases. Create backup copies of your databases in SQL Server 2012 To back up a database in SQL Server Open SQL Server Management Studio and connect to the appropriate instance of the SQL Server 2012 Database Engine. 2. In the Object Explorer pane, expand Databases, right-click the database that you want to back up, click Tasks, and then click Back Up. 3. In the Back Up Database dialog box, on the General page, in the Source section, click the Database dropdown menu and select the database that you want to back up. 4. In the Backup type box, select Full. 5. For the Backup component, select Database. 6. In the Backup set section, in the Name box, either accept the default backup set name or type a new name.

213 7. In the Destination section, specify the type of backup destination by selecting Disk or Tape. Click Add. In the Select Backup Destination dialog box, click the Browse button. In the Locate Database Files dialog box, in the File name box, type a name for the backup file. Click OK. 8. In the General page, click OK to start the backup process. The status of the backup process will appear in the Progress section. When the process has completed successfully, a dialog box appears that states that the backup has completed successfully. Click OK. The backup file can be found in the location noted in the Destination section. Repeat the previous procedure to back up the remaining required databases. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears. See also Plan for upgrade to Project Server 2013 Upgrade to Project Server 2013 What's new for upgrade (Project Server 2013) Prepare your environment for upgrade (Project Server 2013) Restore your Project Server 2010 farm databases for upgrade (Project Server 2013)

214 Restore your Project Server 2010 farm databases for upgrade (Project Server 2013) 12/13/ min to read Edit Online Summary: Restore your Project Server 2010 databases to the SQL Server instance that is hosting your Project Server 2013 data. Applies to: Project Server 2013 This is one of the required steps when you upgrade from Project Server 2010 to Project Server 2013 through the database-attach upgrade method. After you have configured the Project Server 2013 destination environment, you can restore the backup copies of the Project Server 2010 databases on the SQL Server instance that you are using to host your Project Server 2013 databases. This requires you to have backup copies of your Project Server 2010 databases and the SharePoint content database used to host your Project Web App site data. For information about how to create backup copies of these databases, see Create backup copies of your Project Server 2010 farm databases for upgrade (Project Server 2013). The Project Server 2010 databases that are required for upgrading to Project Server 2013 include the following: Project Server Draft Project Server Archived Project Server Published Project Server Reporting SharePoint content database that contains your Project Web App site data The following sections describe how to restore the backup copies of these databases on the SQL Server instance that you are using to host your Project Server 2013 databases. These include procedures in each of the SQL Server versions that are supported for use with Project Server 2010: SQL Server 2008 or SQL Server 2008 R2 SQL Server 2012 After you have restored the backup copies of the Project Server 2010 databases, you can upgrade the databases and the Project Web App site collection. For more information, see Upgrade to Project Server Restore your Project Server 2010 databases in SQL Server 2008 or SQL Server 2008 Release 2 To restore a backup copy of a database in SQL Server 2008 Enterprise 1. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name. 2. In Object Explorer, right-click Databases, and then click Restore Database. The Restore Database dialog box appears. 3. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.

215 4. In the To a point in time box, keep the default ( Most recent possible). 5. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file. 6. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected. 7. In the Backup location area, click Add. 8. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK. 9. In the Restore Database dialog box, under the Select the backup sets to restore grid, select the Restore check box next to the most recent full backup. 10. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box. 11. Click OK to start the recovery process. Repeat the previous procedure to restore the remaining required databases. To restore a backup copy of a database in SQL Server Open SQL Server Management Studio, and connect to the appropriate instance of the SQL Server 2012 Database Engine. 2. In the Object Explorer pane, right-click Databases, and then click Restore Database. The Restore Database dialog box appears. 3. In the Restore Database dialog box, select the General page. In the Source section, select Device and then click the Browse button. 4. In the Select backup devices dialog box, click Add. 5. In the Locate Backup File dialog box, locate and select the database that you want to restore. Click OK. 6. In the Select backup devices dialog box, click OK. 7. On the General page, in the Restore plan section, in the Backup sets to restore list, verify that the Restore check box is selected for the database that you are restoring. 8. In the Destination section, in the Database field, you can type a new database name if you want to change it from the previous name. 9. Click OK to start the restore process. The status will appear in the status bar on the top of the page. 10. When the restore process is complete, a dialog box is displayed that states that the database was restored successfully. Click OK. Repeat the previous procedure to restore the remaining required databases. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears.

216 See also Plan for upgrade to Project Server 2013 Upgrade to Project Server 2013 What's new for upgrade (Project Server 2013) Prepare your environment for upgrade (Project Server 2013) Create backup copies of your Project Server 2010 farm databases for upgrade (Project Server 2013)

217 Upgrade your databases and Project Web App site collections (Project Server 2013) 12/13/ min to read Edit Online Summary: How to upgrade your required Project Server 2010 databases and your Project Web App site collection to Project Server Applies to: Project Server 2013 This article is one is a series of articles for upgrade to Project Server We recommend that you read the following articles before you try any procedures in this article: Plan for upgrade to Project Server 2013 Prepare your environment for upgrade (Project Server 2013) Create backup copies of your Project Server 2010 farm databases for upgrade (Project Server 2013) Restore your Project Server 2010 farm databases for upgrade (Project Server 2013) What's new for upgrade (Project Server 2013) After restoring your Project Server 2010 databases and the SharePoint content database that contains your Project Web App site data, you can then run the steps necessary to upgrade the data and the Project Web App site collection to Project Server The actual upgrade process can be divided into two separate phases: SharePoint upgrade phase: Check the SharePoint content database that contains your Project Site data for errors that can cause upgrade to fail. Attach and upgrade the SharePoint content database. Take ownership of the site collection you want to upgrade. Migrate users from Windows Classic authentication to claims-based authentication (optional). Check the SharePoint site for issues that can cause upgrade to fail. Upgrade the SharePoint Site. Project Server upgrade phase: Consolidate your Project Server 2010 databases to a Project Web App database. Attach your Project Web App database to the web application. Upgrade your Project Web App database. Mount your Project Web App Instance. Upgrade your Project Web App Instance. Enable the PWA feature. SharePoint upgrade phase

218 STEPS REQUIRED MICROSOFT POWERSHELL CMDLET 1 Check the SharePoint content database that contains your Project Site data for errors that can cause upgrade to fail. Test-SPContentDatabase 2 Attach and upgrade the SharePoint content database. Mount-SPContentDatabase 3 Take ownership of the site collection you want to upgrade. Set-SPSite 4 Migrate users from Windows Classic authentication to claims-based authentication (optional). > [!NOTE]> This step is only required if your Project Server 2010 web application is using Classic Windows authentication, and your Project Server 2013 web application is using claimsbased authentication. (Get-SPWebApplication ).MigrateUsers($true) 5 Check the SharePoint site collection for issues that can cause upgrade to fail. Test-SPSite 6 Upgrade the SharePoint site. Upgrade-SPSiteUpgrade-SPSite 1. Check the SharePoint Content database for errors that can cause upgrade to fail Run the Test-SPContentDatabase cmdlet to check the SharePoint Server 2010 content database prior to running the Mount-SPContentDatabase cmdlet to connect the SharePoint 2010 database to the farm. The Test- SPContentDatabase cmdlet is a non-destructive test operation that checks the database and post errors that prevent upgrade of the database. Test-SPContentDatabase -Name <contentdbname> -WebApplication <URL> -ServerInstance <servername> For example: Test-SPContentDatabase -Name PWA_ContentDB -WebApplication -ServerInstance SQLServer1 REQUIRED PARAMETERS -Name -WebApplication -ServerInstance Running the Test-SPContentDatabase cmdlet checks the SharePoint Server 2010 content database and posts any possible errors in the data. It provides a description of the error, possible remedy, and an UpgradeBlocking flag to note if the error will prevent an upgrade of the database. It is important to address any errors in which the UpgradeBlocking flag is set to a value of True.

219 2. Attach and Upgrade the SharePoint Content Database Run the Mount-SPContentDatabase Microsoft PowerShell cmdlet to connect the SharePoint Server 2010 database to the specified Web Application and also upgrade the database. Ensure that the account that you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade. Note Using the SharePoint Central Administration pages to attach a content database is not supported for upgrading. Mount-SPContentDatabase -Name <contentdbname> -WebApplication <URL> -DatabaseServer <servername> -NoB2BSiteUpgrade For example: Mount-SPContentDatabase -Name PWA_ContentDB -WebApplication -DatabaseServer SQLServer1 -NoB2BSiteUpgrade REQUIRED PARAMETERS -Name -WebApplication -DatabaseServer -NoB2BSiteUpgrade 3. Add your account as a secondary owner of the PWA site collection that you want to upgrade You must add yourself as an owner of the PWA site collection. This is required for the proceeding steps in which you have to verify and then upgrade the site collection. Set-SPSite -Identity <sitecollectionname> -SecondaryOwnerAlias <account> For example: Set-SPSite -Identity -SecondaryOwnerAlias "contoso\\farmadmin" REQUIRED PARAMETERS -Identity -SecondaryOwnerAlias 4. Migrate users who are using Windows Classic authentication mode to claims based authentication (optional) If you are migrating Project Server 2010 users who were using Windows Classic authentication over to claimsbased authentication when upgrading to Project Server 2013, you will need to run the following Windows PowerShell cmdlet. If this is not done, your users will not be able to log on to Project Web App after upgrade. (Get-SPWebApplication <webappurl>).migrateusers($true)

220 For example: (Get-SPWebApplication For more information about this method, see SPWebApplication.MigrateUsers Method. 5. Check your PWA Site collection for issues that can cause upgrade of the site to fail The Project Web App site does not support SharePoint Server 2010 version mode. The site collection for PWA must be upgraded in order to work in Project Server It is important to note that this requirements in only for PWA, and that core SharePoint site collections do not require this. Prior to upgrading the site collection, we recommend that you run the Test-SPSite cmdlet to verify if the site collection has any issues that can cause upgrade of the site collection to fail. You can review the results and fix any upgrade blocking issues. Test-SPSite -Identity <URL> For example: Test-SPSite -Identity REQUIRED PARAMETERS -Identity The results display the number of "FailedWarningCounts" that it discovered through the test, but will not display information about the failure. To find more information about the failure, you can navigate to the PWA Site Settings page and run a health check on the site collection by doing the following: To run a health check on the PWA site collection to view upgrade warning information 1. In a browser window, enter the URL for the site (for example, At the end of the URL, type the following: /_layouts/15/settings.aspx. In this example, the complete URL would be This gives you a direct link to the Site Setting page. You cannot display the PWA site page because it has not been upgraded and is still in SharePoint Server 2010 mode. 2. On the PWA Site Settings page, in the Site Collection Administration section, click Site Collection Health Checks. Note Notice that a message displays at the top of the page stating that the page is in SharePoint 2010 mode, because the site collection has not been upgraded yet. 3. On the Run Site Collection Health Checks page, click Run checks to start a health check on the site collection. 4. The results of the health check will display verbose information about any warnings that were found by the Test-SPSite cmdlet. For example, it will tell you if any pages may have been customized and may cause unexpected behavior after upgrade. It will provide the page URL and an option to reset the page to default. Caution

221 Before using the option to reset the page to default, make sure that you track the customization that were implemented on the page so that you can manually re-create them after upgrade. Resetting the page to default will return the page to the default template, and will remove your customizations that were implemented on the page. 6. Upgrade the Project Web App site from SharePoint 2010 mode After checking the PWA site collection and correcting any issues that can cause upgrade to fail, you can run the Upgrade-SPSite Microsoft PowerShell cmdlet to upgrade the PWA site to SharePoint Upgrade-SPSite -Identity <URL> -versionupgrade For example Upgrade-SPSite -Identity -versionupgrade REQUIRED PARAMETERS -Identity -versionupgrade Project Server upgrade phase After you complete the SharePoint Upgrade phase, you will be able to connect to the PWA site, but will be unable to view any project data because the Project Server 2010 database have not been connected and upgraded yet. Use the following steps in the Project Server upgrade phase to complete the upgrade. STEPS REQUIRED MICROSOFT POWERSHELL CMDLET 1 Consolidate your Project Server 2010 databases to a Project Project Web App database Convertto-SPProjectDatabase 2 Attach your Project Web App database to the web application. Mount-SPProjectDatabase 3 Check your Project Web App database for errors Test-SPProjectDatabase 4 Upgrade your Project Web App database Upgrade-SPProjectDatabase 5 Mount your Project Web App Instance Mount-SPProjectWebInstance 6 Check your Project Web App instance for errors Test-SPProjectWebInstance 7 Upgrade your Project Web App Instance Upgrade-SPProjectWebInstance 8 Enable PWA features Enable-SPfeature

222 1. Consolidate your Project Server 2010 databases to a Project Web App database Run the Convertto-SPProjectDatabase Microsoft PowerShell cmdlet to consolidate your restored Project Server 2010 databases to a single Project Server 2013 Project Web App database. This cmdlet also connects the new Project Server 2013 Project Web App database to the Project Server 2013 web application. Convertto-SPProjectDatabase -WebApplication <URL> -Dbserver <databaseservername> -ArchiveDbname<ArchivedbName> - DraftDbname<DraftdbName> -PublishedDbname<PublisheddbName> -ReportingDbname<ReportingdbName> - ProjectServiceDbname<ProjectWebAppdbName> For example: Convertto-SPProjectDatabase -WebApplication -Dbserver SQLServer1 -ArchiveDbname ContosoProjectArchived - DraftDbname ContosoProjectDraft -PublishedDbname ContosoProjectPublished -ReportingDbname ContosoProjectReporting - ProjectServiceDbname ContosoProjectWebApp1 REQUIRED PARAMETERS -WebApplication -Dbserver -ArchiveDbname -DraftDbname -PublishedDbname -ReportingDbname -ProjectServiceDbname When you run the cmdlet, you are prompted for a confirmation that you want to continue. Type Y to continue. After running this cmdlet successfully, you will see a confirmation message of "Conversion of Project Databases complete." You will also see the new Project Web App database on the computer that is running SQL Server. 2. Attach the Project Services database to the web application Run the Mount-SPProjectDatabase Microsoft PowerShell cmdlet to attach your new Project Web App database to the web application that you had created earlier in your Project Server 2013 environment. Mount-SPProjectDatabase -Name <ProjectWebAppdbName> -WebApplication<URL> -DatabaseServer <databaseservername> For example: Mount-SPProjectDatabase -Name ContosoProjectWebApp1 -WebApplication -DatabaseServer SQLServer1 REQUIRED PARAMETERS -Name -WebApplication

223 REQUIRED PARAMETERS -DatabaseServer When the Mount-SPProjectDatabase cmdlet is finished, it will return you to the Microsoft PowerShell command prompt. Currently, you will not see a confirmation message upon successful completion. 3. Check your Project Web App database for errors that can cause upgrade to fail Run the Test-SPProjectDatabase cmdlet to check your Project Web App database for issues that can cause upgrade of this database to fail. The Test-SPProjectDatabase cmdlet is a non-destructive test operation that will check the database and will post error that will prevent upgrade of the database. Test-SPProjectDatabase -Name <contentdbname> -DatabaseServer <DBServerName> For example: Test-SPProjectDatabase -Name ContosoProjectWebApp1 -DatabaseServer SQLServer1 -Name -Databaseserver Specifies the name of your Project Web App database. Specifies the instance of the database service on which the Project Web App database is located. The type must be a valid GUID, such as ab-cdef bcdefgh; a valid name of a SQL Server instance (for example, DBSvrInstance1); or an instance of a valid SPDatabaseServiceInstance object. Running the Test-SPProjectDatabase cmdlet will check your Project Web App database and will post any possible errors in the data. It provides a description of the error, possible remedy, and an UpgradeBlocking flag to note if the error will prevent an upgrade of the database. It is important to address any errors in which the UpgradeBlocking flag is set to a value of True. 4. Upgrade the Project Web App database Run the Upgrade-SPProjectDatabase Microsoft PowerShell cmdlet to upgrade your new Project Web App database to Project Server The four Project Server 2010 databases were merged to the Project Web App database by the Convertto-SPProjectDatabase in step 1. Upgrade-SPProjectDatabase -Name <ProjectWebAppdbName> -WebApplication <URL> -DatabaseServer <databaseservername> For example: Upgrade-SPProjectDatabase -Name ContosoProjectWebApp1 -WebApplication -DatabaseServer SQLServer1 REQUIRED PARAMETERS -Name -WebApplication

224 REQUIRED PARAMETERS -DatabaseServer When you run the cmdlet, you are prompted for a confirmation that you want to continue. Type Y to continue. When the Upgrade-SPProjectDatabase cmdlet is finished, it will return you to the Microsoft PowerShell command prompt. Currently, you will not see a confirmation message upon successful completion. 5. Mount the Project Web App instance Run the Mount-SPProjectWebInstance Microsoft PowerShell cmdlet to connect your new Project Web App database to a Project Web App instance in Project Server Mount-SPProjectWebInstance -DatabaseName <ProjectWebAppdbName> -SiteCollection<URL> -DatabaseServer <databaseservername> For example: Mount-SPProjectWebInstance -DatabaseName ContosoProjectWebApp1 -SiteCollection -DatabaseServer SQLServer1 REQUIRED PARAMETERS -DatabaseName -SiteCollection -DatabaseServer When you run the cmdlet, you are prompted for a confirmation that you want to continue. Type Y to continue. 6. Check the Project Web App instance for issues that can cause upgrade to fail Prior to trying to upgrade the Project Web App instance, run the Test-SPProjectWebInstance Microsoft PowerShell cmdlet to check the Project Web App instance for issues that can cause upgrade to fail. This cmdlet checks for issues such as if the Project Business Intelligence (BI) Center exists for all project sites, or if there are unprocessed jobs in the queue and also queue status, and for issues with project workspaces. The result of the test appears in Microsoft PowerShell, but the information is more readable if you export the results to a text file. Use the results to address any issues with a "FailedWarning" status. Test-SPProjectWebInstance -Identity <URL or Site ID> For example: Test-SPProjectWebInstance -Identity REQUIRED PARAMETERS -Identity 7. Upgrade the Project Web App instance Run the Upgrade-SPProjectWebInstance Microsoft PowerShell cmdlet to upgrade the Project Web App instance to Project Server 2013.

225 This cmdlet checks for issues such as if the Project Business Intelligence (BI) Center exists for all project sites, or if there are unprocessed jobs in the queue and also queue status, and for issues with project workspaces. The results of the test will display in Microsoft PowerShell, but the information will be more readable if you export the results to a text file. Use the results to address any issues with a "FailedWarning" status. Upgrade-SPProjectWebInstance -Identity <URL or site ID> For example: Upgrade-SPProjectWebInstance -Identity REQUIRED PARAMETER -Identity When you run the cmdlet, you are prompted for a confirmation that you want to continue. Type Y to continue. After you run this cmdlet successfully, you see a confirmation message of "Upgrade of single project site completed." 8. Enable Project Web App features Run the Enable-SPFeature Microsoft PowerShell cmdlet to enable the PWA site feature on the site collection. Enable-SPFeature -Identity pwasite -URL <ProjectSiteCollection> For example: Enable-SPFeature -Identity pwasite -URL REQUIRED PARAMETER -Identity -URL When the Enable-SPFeature cmdlet finishes, it returns you to the Microsoft PowerShell command prompt. Currently, you will not see a confirmation message upon successful completion. Open your Project Web App site URL to view your upgraded site and data. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears.

226 See also Plan for upgrade to Project Server 2013 What's new for upgrade (Project Server 2013) Prepare your environment for upgrade (Project Server 2013) Restore your Project Server 2010 farm databases for upgrade (Project Server 2013) Create backup copies of your Project Server 2010 farm databases for upgrade (Project Server 2013)

227 Post-upgrade tasks (Project Server 2013) 12/13/ min to read Edit Online Summary: After you upgrade to Project Server 2013, you must address additional tasks. Applies to: Project Server 2013 After upgrading to Project Server 2010, you must address two post-upgrade tasks: Enable Issues and Risks links. Add the Project Server 2013 Enterprise Project Type (EPTs) Enable Issues and Risks links After upgrading to Project Server 2013, Issues and Risk links in your upgraded project plans will not function and require the following in order for them to work properly: Bulk update of all project sites - You will need to change the site path information for your upgraded project sites since they have been moved from one Web application to another. You can do this through the Bulk Update Project Sites page in the Project Web App settings located in SharePoint Central Administration. For more information about the Bulk Update Project Sites page, seebulk Update Project Sites (Project Server 2013 settings). Publish all projects with associated project sites - After updating your site path information for your project sites through the Bulk Update Project Sites page, you will need to publish each project that contains an associated project site. This is required so that the Project Server 2010 links for Issues and Risks are moved to Project Server 2013, which occurs when the project is published. If the project is not published, the link items will not display. Important Document library links to tasks in Project Server 2010 are not migrated to Project Server 2010 during the upgrade process. Although your Document library links may function in Project Server 2010, when they are upgraded to Project Server 2013, they will no longer display since they are not upgraded. However, new Document library links can be added in Project Server Add the Project Server 2013 Enterprise Project Types A known issue after you upgrade from Project Server 2010 to Project Server 2013 is that on the Project Center page, if you click New on the ribbon, you only see the Basic Project EPT that was migrated from Project Server You do not see the two default EPTs that are installed with Project Server 2013: Enterprise Project SharePoint Tasks List The following procedures allow you to correct this problem so that you can access and use the default EPTs for Project Server This process requires two procedures: Add the SharePoint Tasks Lists EPT Rename the Basic Project EPT to "Enterprise Project"

228 After you complete the procedures, the Enterprise Project Types page displays the SharePoint Tasks Lists and Enterprise Project EPTs. To add the SharePoint Tasks List as an Enterprise Project Type 1. In Project Web App, click the Settings icon, and then click Project Web App Settings. 2. On the Project Web App settings page, in the Workflow and Project Details Pages section, click Enterprise Project Types. 3. On the Enterprise Project Types page, click New Enterprise Project Type. 4. On the Add Enterprise Project Type page, enter the information needed for the SharePoint Tasks List enterprise project type: For the Name field, typesharepoint Tasks List. For the Description field, typeuse this type to create a SharePoint Tasks List Project with some basic information (like name, start date, end date) and a schedule. In the SharePoint Tasks List Project section, select Create new projects as SharePoint Tasks List Projects. In the New Project Page/Project Details Pages section, in the New Project Page list, select Project Details. In the Available Project Details Pages list, move Project Details and Schedule to the box on the right. Use the Up/Down buttons to ensure that Project Details is listed first and Schedule is listed second. In the Defaults section, select Use this as the default Enterprise Project Type during Project Creation. In the Image section, in the Type the URL field, type/_layouts/15/inc/pwa/images/centernormalproject.png. This specifies the location of the default image for the SharePoint Tasks List EPT. Click Click here to test to verify that the image is found in the default location. 5. Leave each of the other options with the default value, and then click Save. To rename the Basic Project Enterprise Project Type 1. In Project Web App, click the Settings icon, and then click Project Web App Settings. 2. On the Project Web App settings page, in the Workflow and Project Details Pages section, click Enterprise Project Types. 3. On the Enterprise Project Types page, in the Name column, click Basic Project. 4. On the Basic Project page, in the Name field, change the text toenterprise Project, and then click OK. 5. Click Save. The Enterprise Project EPT now displays on the Enterprise Project Types page. Project Server forums and documentation feedback If you have additional questions, try the Project forums. The Project forums give you the chance to have your question discussed by other participants, Project MVPs, and Project community experts. If you would like to provide feedback on this article, choose the Yes or No option for Did you find this article helpful? located at the end of this page, and then type your feedback in the box that appears.

229 See also Upgrade to Project Server 2013

230 Operations for Project Server 12/13/ min to read Edit Online Summary: The following articles help you operate and maintain a Project Server deployment. TechNet articles about operations for Project Server The following articles about operating and maintaining Project Server are available to view online: OLAP database management in Project Web App Periodic tasks for Project Server administrators Project Server 2013 backup and restore Queue and database administration(project Server 2013) Exchange Server calendar OOF integration with Project Server 2013

231 OLAP database management in Project Web App 12/13/ min to read Edit Online Summary: Use Project Web App to create OLAP databases containing the specific resources, projects, and custom fields that you need for reporting. Applies to: Project Server 2016 Through Project Web App, multiple OLAP databases can be delivered that contain the specific resources, projects, and custom fields that each group within your organization requires for its particular group reporting needs. In Project Web App, you can create multiple OLAP databases that have the following characteristics: They only contain data for projects and resources that they administer. They only contain facts and dimensions that they select from the new integrated OLAP database management user interface. They support departmental filtering to restrict which projects, custom fields, and resources are loaded into the OLAP database. They support selection of intrinsic measures for inclusion/exclusion. For example, you can remove fields that you may not use, such as baseline cost 7, to reduce data clutter. They include data for Inactive Tasks and User Scheduled Tasks. They let you choose whether to add Timephased/NonTimephased data. They have support for Multiple Measure groups in a single OLAP database. They contain field names in multiple languages to enable multi-language report creation. Also, when a new OLAP database is created, the necessary Office Data Connections and Excel Reporting templates are created in the Business Intelligence Center in the Reports folder. This data-connected blank template will help you quickly create new reports that are based on the new OLAP database. Project Web App departments for filtering in project and resources Both projects and resources can have departments. The main purpose of departments is to act as a filter for what custom fields are displayed to users within given areas of Project Professional 2016 and Project Web App. Departments allow for different business units to define and make visible their own set of custom fields. Departments are also used to filter OLAP databases so that only the data for that department is loaded. When you configure a cube, you can specify both the project and resource departments so that the database data is filtered based on these criteria. These values are specified in the OLAP Database Build Settings page. Also, within the OLAP database configuration, you can add the Project department field as a dimension to the Project and Tasks cubes. And you can add the Resource department field as a dimension to the Resource cube as long as the department field has not been converted to a multi-value field. With Project Web App, departmental custom fields help relieve the problem of too much information and too many choices. Departments help you manage the custom field list, and help you define, at a resource, task, or project level, which fields are required or not required. In Project Web App, fields can be globally scoped or they can be scoped to a specific department. Departmental fields enable two primary functions:

232 Filtering custom fields so that a user sees, by default, only those fields that are either global to the system or in the department that the user belongs to. Controlling which fields require input. Example of departments in use FIELD SCOPE DEPARTMENT REQUIRED? ProjectCustomText1 Global - No ProjectCustomText2 Global - Yes ProjectCustomText3 Department Marketing No ProjectCustomText4 Department Marketing Yes ProjectCustomText5 Department Development Yes ProjectCustomText6 Department Development No If John Woods belongs to the Development department, then when he views areas of the product that have departmental custom fields enabled, he sees the following: ProjectCustomText1 ProjectCustomText2 ProjectCustomText5 ProjectCustomText6 John will be required to enter data into ProjectCustomText2 and ProjectCustomText5. Cindy White belongs to the Marketing department. When she views areas of the product that have departmental custom fields enabled, she sees the following: ProjectCustomText1 ProjectCustomText2 ProjectCustomText3 ProjectCustomText4 Cindy will be required to enter data into ProjectCustomText2 and ProjectCustomText4. By default, departments filter the list of custom fields that John Woods and Cindy White see. But the filter does not prevent them from viewing custom fields assigned to the other departments. Departmental fields are not tied into security. You cannot use them with security categories and groups to enable or disable fields and their functions. Instead, their main purpose is to filter out fields which are not useful for the target user. Department considerations for cubes

233 WHICH CUBES ARE FILTERED BY WHICH VALUE NO PROJECT DEPARTMENT SPECIFIED PROJECT DEPARTMENT SPECIFIED No resource department specified All data is loaded for all cubes Project non-timephased cube Task non-timephased cube Issues cube Risks cube Deliverables cube MSP_Project_WSS virtual cube MSP_Project_Timesheet virtual cube MSP_Portfolio_Analyzer virtual cube Assignment non-timephased cube Assignment timephased cube EPM timesheet cube Resource department specified Assignment non-timephased cube Assignment timephased cube Resource non-timephased cube Resource timephased cube Timesheet cube MSP_Project_Timesheet virtual cube MSP_Portfolio_Analyzer virtual cube Filtered by Project Department: Project non-timephased cube Task non-timephased cube Issues cube Risks cube Deliverables cube MSP_Project_WSS virtual cube Filtered by Resource & Project Department: Assignment non-timephased cube Assignment timephased cube EPM timesheet cube MSP_Project_Timesheet virtual cube MSP_Portfolio_Analyzer virtual cube Filtered by Resource Department: Resource no- timephased cube Resource timephased cube Timesheet cube Cubes include assignments for resources in projects that belong to other departments or to no department. This ensures that all data is present when examining data such as a department's resources full calendar capacity. The subset of projects and resources will be used to filter at the project and timesheet level as follows: Project non-timephased: The data in this cube will be filtered by the departmental project list. Projects with assignments to the department's resources will be included. Task non-timephased: Non-departmental tasks with assignments to the department's resources will be included. The full nondepartmental project will not be included. All tasks for departmental projects will be included. Assignment non-timephased: Non-departmental project assignments for the department's resources will be included. All assignments for departmental projects will be included. Assignment timephased: Non-departmental project assignments for the department's resources will be included. All assignments for departmental projects will be included.

234 Deliverables: All deliverables owned by the filtered list of projects will be included. All deliverables to which the filtered list subscribes and the projects/tasks that subscribe to the filtered list's deliverables will be included. All deliverables offered by non-departmental projects that are subscribed to by departmental projects will be included. Issues: Risks: Issues connected to the filtered list of projects and tasks will be included. Risks connected to the filtered list of projects and tasks will be included. Resource non-timephased: Resources in the departmental list will be included. Resource timephased: Resources in the departmental list will be included. Timesheet: Timesheets for departmental list resources will be included. EPM Timesheet: Timesheets for departmental list resources will be included. Task assignments from projects outside the department will be included. Resources are described in three ways in the OLAP databases: Fact focus (timesheets, capacity) Associated with Facts (project task assignments) Owning Facts (project owner, issue owner, assignment owner) The departmental resource list is used to filter facts with focus (Timesheets). Consequently, a non-departmental resource will never have any timesheets or capacity in the OLAP database if the database has a resource filter. However the non-departmental resource will be in the Resource List dimension if it has association with a departmental project, and will only have the relevant assignment facts. Resources who own things that have separate dimensions (that is, Assignment Owner) do not have to be in the resource list. The Resource List dimension for a specific OLAP database contains: The departmental resources All resources with assignments to departmental projects See also Create OLAP cubes in Project Server 2016 Configure an OLAP cube in Project Server 2016 Copy OLAP cubes in Project Server 2016

235 Delete OLAP cubes in Project Server 2016 Build OLAP cubes in Project Server 2016

236 Create OLAP cubes in Project Server /13/ min to read Edit Online Summary: Manage OLAP cubes by using the OLAP Database Management page in Central Administration. Applies to: Project Server 2016 To create an OLAP cube, you must be a Project Server service application administrator. Perform the following procedure to create a new OLAP cube. To create an OLAP cube by using Project Web App 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Queue and Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, click New. 6. Configure the settings on the OLAP Database Build Settings page: SETTING DESCRIPTION Analysis Services Server Analysis Services Database to be created Extranet URL Description Project Departments Resource Departments Use the earliest project start date and the latest project finish date The name of the instance of SQL Server Analysis Services (SSAS) where you want to build the cube. The name of the database that you want to create. The URL for the extranet site. A description of this OLAP cube. If you have projects assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs. The selection of departments available is controlled by the Department custom lookup table. If you have resources assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs. The selection of departments available is controlled by the Department custom lookup table. Select this option if you want to base the date range of the cube on the earliest start date of any project and the latest finish date of any project.

237 SETTING Use the following last and next time units to calculate the date range at the time that the OLAP database is built Use the fixed date range specified below Update periodically Immediately retry the OLAP database update if scheduled time fails because of queue down time Update every Start date Start time DESCRIPTION Select this option if you want the date range to be configured automatically based on a delta from the date on which the cube is built. In the Last and Next boxes, type the number of days, weeks, or months that you want to use for the delta. Select this option if you want to use a fixed date range. In the From and To boxes, type the dates that you want to use. Select this option if you want to schedule an update frequency. If this option is not selected, the cube is not updated automatically. If the scheduled cube build fails because the queue is not available, selecting this option causes the build job to start automatically when the queue becomes available instead of waiting for the next scheduled time. Select the number of hours, days, weeks, or months for the cube to be rebuilt. Select the start date for the first automated cube build. Select the start time for each automated cube build. 1. Click Save. See also Configure an OLAP cube in Project Server 2016 Delete OLAP cubes in Project Server 2016 Build OLAP cubes in Project Server 2016

238 Configure an OLAP cube in Project Server /13/ min to read Edit Online Summary: Configure OLAP cube settings by using the OLAP Database Management page in Central Administration. Applies to: Project Server 2016 You can configure OLAP cube dimensions and measures, or you can configure the build settings of a cube. To configure an OLAP cube, you must be a Project Server service application administrator. There are two sets of parameters that can be configured on an existing OLAP cube: Dimensions and measures Cube build settings Perform the following procedure to configure the dimensions and measures of an existing OLAP cube. To configure OLAP cube dimensions and measures 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, select an OLAP database from the list, and then click Configuration. 6. Configure the settings on the Database Configuration page: SETTING DESCRIPTION Cube Dimensions Cube Measures Use the Cube dimensions area to specify the custom fields that you want to add to the OLAP cube as dimensions. Select a cube from the drop-down list to display the available and selected dimensions. Select the dimensions that you want to include in that cube in the Available fields list and click Add to include them in the cube. Do this for each cube in the Cube drop-down list. Use the Cube measures area to specify the custom fields that you want to add to the OLAP cube as measures. Select a cube from the drop-down list to display the available and selected measures. Choose the measures that you want to include in that cube in the Available fields list and click Add to include them in the cube. Do this for each cube in the Cube drop-down list.

239 SETTING DESCRIPTION Built-in Measures Inactive Tasks Calculated Measures Select the built-in measures that you want to include in the cube. The fields that you select are added to the Project, Task, and Assignment cubes as measures. If you want the cube to include inactive tasks, select the Include Inactive Tasks check box. Select the cube that you want to define an expression for from the Cube drop-down list, and then click Insert to add a custom MDX expression. For more information about MDX expressions, see Multidimensional Expressions (MDX) Reference ( 1. Click Save. Perform the following procedure to configure the build settings of an existing OLAP cube. To configure OLAP cube build settings 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, in the OLAP Database Name column, click the database that you want to configure. 6. Configure the settings on the OLAP Database Build Settings page: SETTING DESCRIPTION Analysis Services Server Analysis Services Database to be created Extranet URL Description The name of the instance of SQL Server Analysis Services (SSAS) where you want to build the cube. The name of the database that you want to create. The URL for the extranet site. A description of this OLAP cube.

240 SETTING Project Departments Resource Departments Use the earliest project start date and the latest project finish date Use the following last and next time units to calculate the date range at the time that the OLAP database is built Use the fixed date range specified below Update periodically Immediately retry the OLAP database update if scheduled time fails because of queue down time Update every Start date Start time DESCRIPTION If you have projects assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs. The selection of departments available is controlled by the Department custom lookup table. To allow multiple selections, modify the Project Departments custom field and select the Allow multiple values to be selected from lookup table check box. > [!NOTE]> To cancel the selection of a department after it is selected, click the department again. If you have resources assigned to departments, you have the option of selecting the departments that you want to have included in the cube. If no department is selected, then no departmental filtering occurs. The selection of departments available is controlled by the Department custom lookup table. To allow multiple selections, modify the Resource Departments custom field and select the Allow multiple values to be selected from lookup table check box. > [!NOTE]> To cancel the selection of a department after it is selected, click the department again. Select this option if you want to base the date range of the cube on the earliest start date of any project and the latest finish date of any project. Select this option if you want the date range to be configured automatically based on a delta from the date on which the cube is built. In the Last and Next boxes, type the number of days, weeks, or months that you want to use for the delta. Select this option if you want to use a fixed date range. In the From and To boxes, type the dates that you want to use. Select this option if you want to schedule an update frequency. If this option is not selected, the cube will not be updated automatically. If the scheduled cube build fails because the queue is not available, selecting this option will cause the build job to start automatically when the queue becomes available instead of waiting for the next scheduled time. Select the number of hours, days, weeks, or months for the cube to be rebuilt. Select the start date for the first automated cube build. Select the start time for each automated cube build. 1. Click Save. See also Create OLAP cubes in Project Server 2016

241 Delete OLAP cubes in Project Server 2016 Build OLAP cubes in Project Server 2016

242 Copy OLAP cubes in Project Server /13/ min to read Edit Online Summary: Copy Project Web App OLAP cube settings for use in creating a new cube. Applies to: Project Server 2016 OLAP cubes are managed on the OLAP Database Management page in Server Settings in the SharePoint Central Administration website. To copy an OLAP cube, you must be a Project Server service application administrator. Perform the following procedure to copy an existing OLAP Cube. Copying a cube creates a new cube with the same settings and configuration as the cube that you copied. Copying a cube does not copy the Analysis Services database, but instead copies all the cube settings from which you can build a new Analysis Services database. Note You must specify a new name for the Analysis Services database after you copy the cube. Use the following procedure to copy an OLAP cube. To copy an OLAP cube by using Project Web App 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, select the cube that you want to copy, and then click Copy. 6. On the OLAP Database Build Settings page, type the name of the server and the database that you want created and adjust any other desired settings. 7. Click Save. Note This procedure copies the cube configuration but does not build the cube. You can build the cube manually or wait for it to build on the schedule that you set. See also Create OLAP cubes in Project Server 2016 Configure an OLAP cube in Project Server 2016 Delete OLAP cubes in Project Server 2016 Build OLAP cubes in Project Server 2016

243 Delete OLAP cubes in Project Server /13/ min to read Edit Online Summary: Delete an OLAP cube by using the OLAP Database Management page in Central Administration. Applies to: Project Server 2016 To delete an OLAP cube, you must be a Project Server service application administrator. Perform the following procedure to delete an OLAP Cube. To delete an OLAP cube by using Project Web App 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, select the cube that you want to delete, and then click Delete. Note This procedure deletes the cube and its associated configuration from Project Web App. The actual OLAP database is not deleted from SQL Server Analysis Services (SSAS). For information about deleting the OLAP database from Analysis Services, see How to: Delete an Analysis Services Database or Cube. See also Create OLAP cubes in Project Server 2016 Configure an OLAP cube in Project Server 2016 Build OLAP cubes in Project Server 2016

244 Build OLAP cubes in Project Server /13/ min to read Edit Online Summary: Build OLAP cubes by using the OLAP Database Management page in Central Administration. Applies to: Project Server 2016 OLAP cubes can be scheduled to be built on a regular basis. For more information, see Configure an OLAP cube in Project Server You can also start the build process manually. To build an OLAP cube, you must be a Project Server service application administrator. Perform the following procedure to build an existing OLAP cube. To build an OLAP cube by using Project Web App 1. In Central Administration, in the Application Management section, click Manage service applications. 2. Click the Project Server service application. 3. Point to the Project Web App instance where you want to build the cube, click the arrow that appears, and then click Manage. 4. On the Server Settings page, in the Database Administration section, click OLAP Database Management. 5. On the OLAP Database Management page, select the cube that you want to build, and then click Build Now. See also Create OLAP cubes in Project Server 2016 Configure an OLAP cube in Project Server 2016 Delete OLAP cubes in Project Server 2016

245 Project Server 2013 backup and restore 12/13/ min to read Edit Online Summary: This section covers Project Server 2013 backup and restore information, specific to the Project Server components of a SharePoint Server 2013 farm. Applies to: Project Server 2013 These are useful articles for planning and maintenance, emergency recovery scenarios, or disaster-recovery situations. The following articles provide information about backing up and restoring Project Server Articles about backing up and restoring Project Server 2013 The following articles about backing up and restoring Project Server 2013 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. ** CONTENT** DESCRIPTION Back up Project Server 2013 by using built-in tools Restore Project Server 2013 by using built-in tools Describes how to implement a backup strategy for Project Server farm components by using SharePoint Server and SQL Server tools. Describes how you can do specific restores of Project Server 2013 in multiple ways, whether through a planned event, or as a result of Project Server having real issues that can only be addressed by a restore of a previously known good backup.

246 Back up Project Server 2013 by using built-in tools 12/13/ min to read Edit Online Summary: Learn how to implement a backup strategy for Project Server farm components by using SharePoint Server 2013 and SQL Server tools. Applies to: Project Server 2013 There are three ways to back up Project Server 2013 components located in a SharePoint Server 2013 farm. You can use SQL Server tools to back up the relevant Project Server 2013 databases. You can use the SharePoint Central Administration website to back up the relevant Project Server databases. You can use Microsoft PowerShell to back up the relevant Project Server databases. We recommend a backup for any production environment, or any environment where data loss would be unacceptable. In a SharePoint farm, the ideal method is to back up all content and configuration databases so that you can perform a complete restore, if necessary. Monitor farm resources when backups are taken for performance issues, and if desirable, take your backups during low-usage times. Note To review the backup documentation for a SharePoint Server 2013 farm, see Back up farms in SharePoint For Project Server 2013, there are two core components for backing up, unique to Project Server: a Project Server service application database for each Project Server service application in the farm, and at least one, but possibly more than one, content database that contains Project sites. The methods outlined below show you how to back up these elements. Use SQL Server tools to take Project Server database backups Important This process can also be automated by your database administrator and may already be in place. Discuss backups with your database administrator as needed. To identify Project Server databases in a SharePoint farm 1. Identify the relevant Project Server 2013 databases to be backed up. Go to Start -> All Programs -> Microsoft SharePoint 2013 Products -> SharePoint 2013 Central Administration. 2. Select Application Management from the left-hand navigation. 3. Click Manage service applications, under the Service Applications heading on the following page. 4. On this page, you must select each service application of Type: Project Application Services. Depending on your organizational needs, you may have more than one service application configured. Click the name of the first service application found. 5. On the following page, you may see one or more URLs listed with Project Web App sites created for them. For each one listed, rest your mouse on the URL and then click the drop-down arrow to the right when it appears.

247 6. Select View from the drop-down menu. 7. This page gives you the web application for the Project Web App site, which you can use to determine the content database or databases to back up, and the Project Web App path. Make a note of these. The Database Settings section gives you the Project Web App database name. You should also note this name. 8. To determine the content database name, click Application Management on the left-hand navigation again. 9. Click View all site collections, in the Site Collections section. 10. Here you are able to go to the Web Application: drop-down on the upper-right-hand side of the page. Select the drop-down arrow and choose Change Web Application. 11. Choose the web application identified in step You should now see a list of site collections for this web application. Identify the Project Web App path, from step Once you have selected that site collection, the database that it is located in should be listed in the table to the right. Make note of that name. 14. Repeat this process for each URL listed in your Project Server service application, and for each Project Server service application you have. At this point, you should have the minimum database requirements for a SQL backup listed. To back up Project Server databases from a SharePoint farm by using SQL Server tools 1. On the server hosting the SQL Server installation being used by the SharePoint farm, open Start -> All Programs -> Microsoft SQL Server 2008/2012 -> SQL Server Management Studio. 2. Connect to the server hosting the SQL instance you want to work with by clicking the Connect button. 3. Under your SQL instance on the left-hand side, expand the Databases option. 4. You should now see which databases are listed for this instance. Retrieve the list you completed in step 14 of the previous section. 5. For each database in this list, right-click the database name, and choose Tasks and then Backup on the submenu. 6. Once the Backup window opens, under the General Page, select the Backup Type to be Full ( Differential can be done later, the first backup must be full). Choose a name if the default name is insufficient, and ensure that the destination folder is appropriate and has sufficient space. If not, choose a suitable location. 7. Click OK to perform the backup. 8. Repeat this process for each database in the list. Use Central Administration to take Project Server component backups If you are using this method, discuss it with your database administrator before implementation. SharePoint Server 2013 backups involve using SQL backup methods, and this may be disruptive to a SQL backup schedule. To back up Project Server components by using Central Administration 1. Go to Start -> All Programs -> Microsoft SharePoint 2013 Products -> SharePoint 2013 Central Administration. 2. Select Backup and Restore from the left-hand navigation.

248 3. Select Perform a backup under Farm Backup and Restore. 4. In the Select component to back up section, scroll down to the Shared Services section in the tree view of the page. 5. In the Shared Services section, expand Shared Services Applications. 6. You must select the check box for the Project Server Shared Service in your Shared Services Applications list that you want to back up. The content that relates to each service application should be listed immediately underneath the service application name, and also be auto-checked. Note If you have multiple Project Server Service Applications, each must be backed up separately. 7. Scroll to the bottom of the page and select Next in order to proceed to the Step 2: Select Backup Options page. 8. If this is the first time that you have performed a backup, you must leave the option button for Backup Type to Full. Subsequent backup types may be set to Differential, being aware that the Full backup must be restored before the Differential backup(s). 9. You must have a UNC path, a share, in the \\server\share format, for your backup location. We recommend against using use a share on the same server that the current installation of SharePoint Server is running on, in the event of a critical issue occurring on that server. Note The account running your SharePoint installation's MSSQLSERVER service must have explicit write permissions to the UNC folder, as this is the account which backs up the databases. 10. Click Start Backup, and monitor progress on the Backup and Restore status page until completed. 11. If issues are encountered, review the information found on the Backup and Restore status page, or the backup log located at the path that was specified in step 9. Otherwise the backup should be at the location that was specified in step 9. Use Windows PowerShell to take Project Server component backups You can use Microsoft PowerShell to back up your Project Server 2013 farm manually or as part of a script that can be run at scheduled intervals. To back up Project Server components by using Windows PowerShell 1. On a server in the SharePoint farm, open Start > All Programs -> SharePoint > SharePoint 2016 Management Shell. 2. Right-click the SharePoint 2013 Management Shell and choose Run as administrator from the menu to open the application in administration mode. If UAC prompts you to allow the program to make changes to this computer, and Microsoft PowerShell is listed as the application, select Yes. 3. At the prompt, type the following command: Backup-SPFarm -ShowTree -Directory -BackupMethod [ full/incremental ] -Path 4. This allows you to determine the elements that you will backup, without actually performing the backup, thanks to the -ShowTree parameter. If your service application name is not unique, this should provide you

249 with the full path to enter for -Path instead (if there are spaces, enclose the path with double quotation marks). 5. Once you have identified the Project Server service application to back up, and confirmed with the - ShowTree command, you can remove the -ShowTree command to perform the backup. Backup-SPFarm -Directory -BackupMethod [ full/incremental ] -Path 6. Click Enter. If you add the -Verbose parameter, detailed information is provided about the backup status. If you do not, then a "successful" or error message appears at the end of the backup process. 7. If issues are encountered, review the backup log located at the path that was specified in step 8. Otherwise, the backup will be at the location that was specified at the -Directory parameter. For more information, see Backup-SPFarm. Note We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions. See also Restore Project Server 2013 by using built-in tools

250 Restore Project Server 2013 by using built-in tools 12/13/ min to read Edit Online Summary: You can do specific restores of Project Server 2013 in multiple ways, whether through a planned event, or as a result of Project Server having real issues that can only be addressed by a restore of a previously known good backup. Applies to: Project Server 2013 Sometimes you must do a restore of your Project Server 2013 components, either into a new SharePoint Server 2013 environment or your existing SharePoint Server 2013 environment. If this is the case, your options depend on the SQL Server or SharePoint backups available to you. This article describes scenarios for the restore process for the built-in restore options recommended by Microsoft. Before restoring your Project Server components to a SharePoint farm, make sure that you have reviewed the requirements for SharePoint restoration at Restore farms in SharePoint Some of the decisions which must be made when you are prepared to restore are as follows: Will you restore Project Server into a new environment, or an environment where those components already exist? A new environment may be one that you are moving the Project Server components to, whereas an existing environment may be necessary to restore functionality, and will require overwriting in-place components. What type of backup do you have? If this restore is unplanned, you must confirm what backups options are available for restoring. Do you only have a SQL Server backup? Do you have a SharePoint backup? If this is a planned restore, you can decide what type of backup is most helpful to you by reviewing Back up Project Server 2013 by using built-in tools. You may have several options, which will let you choose the scenario best suited to your needs. In some cases, only one type of backup may be available to you (such as SQL Server backups). Consider the following before you try to restore your Project Server 2013 sites and components: When considering a Project Server 2013 component restore, you'll be restoring at least one Project Server service application (or at least its database) and one or more content databases that contain Project Web Access sites. If you want to restore additional SharePoint components, you can review the SharePoint articles at Backup solutions in SharePoint Scenario one: You have SQL Server database backups You have to restore your Project Server environment to a new farm, and you only have SQL Server backups available. The following steps allow you to restore both your PWA database and your SharePoint content database to a new farm. This exercise assumes that you have one PWA database and one content database that has Project sites in it to restore, and you are restoring to an environment that has Project Server 2013 installed, but not yet configured. It also assumes any custom elements, site definitions, features in the original farm are already installed in the new environment.

251 Note If you have multiple PWA sites or multiple content databases, or both, you must repeat the steps for each database. Organize in advance to avoid confusion over which content databases are used with which service application. To restore SQL Server databases 1. On the server that is hosting the SQL Server installation being used by the SharePoint farm, open Start -> All Programs -> Microsoft SQL Server 2008/2012 -> SQL Server Management Studio. 2. Connect to the server hosting the SQL Server instance that you want to work with by clicking the Connect button. 3. Under your SQL Server instance on the left-hand side, right-click the Databases option, and choose Restore Database from the drop-down menu that appears. 4. In the Restore Database window, select the Device radio button for your Source, on the General page. 5. Click the Build button (three dots to the right of the Device text box), and you will be able to open the Select backup devices window. 6. Click the Add button, and browse to the location of your SQL Server backups. 7. Choose the first database backup that you want to restore (in this scenario it's the PWA database), and then click OK. It should now be listed in the Backup media pane. If so, click OK to return to the Restore Database window. 8. The Files page should not require changes; it will create MDF and LDF files for the database being restored at the default SQL Server location. Change it only if you must. (In a production environment a DBA should make that determination with space and permission issues being considered.) 9. The Options page should not require changes, as this is a new farm, there should be no existing database that has this name. If there is a database that uses the name already present, choose a new name under the General and Files pages for this database. 10. Once you are ready, click OK on the Restore Database page to restore this database. Repeat steps 3 through 10 for the content database that you want to restore to this environment. To restore content databases in Central Administration 1. After restoring both databases, you next have to connect to a server on your SharePoint farm and open Start -> All Programs -> Microsoft SharePoint 2013 Products -> SharePoint 2013 Central Administration. 2. Select Application Management on the left-hand navigation. 3. Choose Manage Web Applications, under the Web Application heading. 4. On the following page, under the Web Applications tab, select New. 5. Create an IIS web site is the option button that should be selected. 6. You must use a unique IIS port or configure it with a Host Header as per your organization's needs and requirements. 7. Authentication and SSL should be similarly configured. 8. We recommend a new application pool, running under a suitable managed account. 9. The database name that you choose should be unique. However, this is a temporary database. Click OK to create this web application.

252 10. Once the web application is created, select Application Management on the left-hand navigation. 11. Click the Manage content databases link under Databases. 12. From the Web Application drop-down on the upper-right, choose Change Web Application if your newly-created web application is not listed. If it is listed, continue to step Select your newly-created web application from the list, and you should be returned to the previous page. 14. The database that you created as part of the web application creation should be listed. Click its name. 15. On the Manage Content Database Settings page, scroll to the bottom and select the Remove content database check box. Click OK to drop this content database from the SharePoint web application. 16. Back on the Content Databases page (which should now have no database names listing), click the Add a content database link. 17. The database server that contains your restored content database should be listed. Add the restored content database name to the Database Name field. 18. You may set the Number of sites before a warning event is generated and the Maximum number of sites that can be created in this database as per your organization's recommendations, but ideally you will set them to be greater than the number of sites existing in the database (if you are unsure how many sites are in the database, leave the numbers at the default settings and adjust later, as needed). Click OK when ready. 19. Now the content database is restored, and the site or sites contained in it should be capable of being browsed. To restore Project Server service application databases in Central Administration 1. In Central Administration, select Application Management on the left-hand navigation. 2. Click the Manage Service Applications link, in the Service Applications. 3. Select New from the Service Applications tab, and then choose Project Server service application from the list. 4. You must give your Project Server service application name, and we recommend that you also make a new application pool, running with a managed account. Leave the Create a proxy option selected, and then click OK to create the service application. 5. Once the service application has finished being created, you should be able to click the name link on the main service application page to open it. 6. Once the service application is open, you must click the Create Project Web App Instance. 7. Choose the web applications that you finished restoring in the previous section. 8. For a database, choose the restored Project Server database, and then click OK. 9. You will return to the main Project Server page, and the provisioning steps continue. Once the process has finished, your Project database is synched up to your PWA content, and your data should be restored into this new environment. Note This becomes more complex with multiple Project Server service applications, as you will want to associate them with the correct content databases. Consult your organization's planning and build documentation or disaster-recovery documentation if you are unsure what your previous configuration may have been.

253 Scenario two: You have Central Administration farm backups You have to restore a backup of your Project Server service application to a last known good configuration, and there is a SharePoint farm backup of this environment. In this scenario, the restore is put into the same environment that the backup was taken from, and you restore only Project Server components from a Full farm backup. To restore a Project Server service application by using SharePoint Central Administration 1. On a server in your SharePoint farm, open Start -> All Programs -> Microsoft SharePoint 2013 Products -> SharePoint 2013 Central Administration. 2. Select Backup and Restore from the left-hand navigation. 3. Click the Restore from a backup link, in the Farm Backup and Restore section. 4. If your job is not listed here, you must enter (in the Backup Directory Location text box) the directory where the farm backup was put. 5. Once you have the correct directory, select the date and time of the backup that you want to restore, and then click the Next button. 6. On the following page, scroll down to the Shared Services Applications listing and expand it. 7. Select the check box for the Project Server Shared Service you want to restore. It will auto-select that service application's components underneath. 8. Click Next at the bottom of the page to continue. 9. The following page will have an option button selection. Choose the Same configuration option, as you are restoring into the same farm. Click OK on the warning box that appears. Note If you were restoring to a new farm, you would want the New configuration option to be selected. 10. Provide an appropriate password for the account in the Login Names and Passwords section. 11. Click the Start Restore button, and monitor the status on the following page until the restore is finished. If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 2. Scenario three: You have a Project Server component backup You have to restore a backup of your SharePoint farm to a last known good configuration, and there is a Project Server component backup of this environment. In this scenario, the restore occurs in a new environment that was built for the restore to match the old environment, excluding these missing components. You are restoring from a Project Server component backup by using Windows PowerShell. To restore Project Server components by using Windows PowerShell 1. On a server in your SharePoint farm, open Start -> All Programs -> Microsoft SharePoint 2013 Products -> SharePoint 2013 Management Shell, right-clicking the SharePoint 2013 Management Shell and selecting Run as administrator on the menu. 2. If the User Account Control box opens asking whether you want to allow the following program to make changes to this computer, and the program is Microsoft PowerShell, click the Yes button to continue.

254 3. To do a restore, some information is needed. The first thing that you have to type is this: Get-SPBackupHistory -Directory -ShowBackup Where is the location of the backup. This enables you to see the GUID entry for the backup or backups at that location after you click the Enter key. Note If you have multiple backups in the same location and are unsure of which GUID might be the one that you want, browse to the backup folder location and open the folder of that backup, and then open the spbackup.xml file in Notepad. The GUID that you must have for the following step will be four lines down, contained in the <SPID> </SPID> tags. 4. After you identify the GUID of the backup that you want to restore, use the following command to restore to the SharePoint farm. Restore-SPFarm -Directory -BackupID -RestoreMethod New Where is the location of the backup and is the GUID of the backup. The RestoreMethod refers to the fact that this is a new farm. A restore to the original farm for these components would require the Overwrite value. Click Enter to run. 5. You may be prompted whether you are sure you want to perform this action. Y is for Yes anda is Yes to All. Note If you were restoring to an existing farm, you would also receive a prompt warning you that existing items will be overwritten, and a Y response here would allow the restore to continue. 6. The restore should continue until it is completed. If there are errors, you can review the restore log located at the backup path. If there are no errors, you should be able to confirm that your Project Server components are now in the restore farm. For more information, see Restore-SPFarm. Note We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions. See also Back up Project Server 2013 by using built-in tools

255 Queue and Database Administration (Project Server 2013) 12/13/ min to read Edit Online Summary: The queue and database administrative settings are part of the Project Server 2013 Server Settings. Applies to: Project Server 2013 The following articles on TechNet provide information about queue and database administration in Project Server Articles about queue and database administration in Project Server 2013 The following articles about queue and database administration in Project Server 2013 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Manage Queue Jobs (Project Server 2013) Daily Schedule Backup (Project Server 2013) Back up item-level objects through Administrative Backup (Project Server 2013) Restore item-level objects through Administrative Restore (Project Server 2013) OLAP database management in Project Web App DESCRIPTION Learn how to manage jobs submitted in Project Server 2013 through the Manage Queue Jobs settings. Use the Daily Schedule Backup settings page in SharePoint Central Administration to schedule daily backups of Project Server 2013 objects. Use the Administrative Backup page in SharePoint Central Administration to back up Project Server 2013 objects. Use the Administrative Restore page in SharePoint Central Administration to restore Project Server 2013 objects. Use Project Web App to create OLAP databases containing the specific resources, projects, and custom fields that you need for reporting.

256 Manage Queue Jobs (Project Server 2013) 12/18/ min to read Edit Online Summary: Learn how to manage jobs submitted in Project Server 2013 through the Manage Queue Jobs settings. Applies to: Project Server 2013 The Manage Queue Jobs page lets you view Project Server 2013 operations ("jobs") that have been processed by the queue system. You can use the configuration options to filter jobs and only see the jobs that you are interested in viewing. You can also retry or cancel jobs through this page. The Project Server 2013 Manage Queue Jobs settings are available through SharePoint Central Administration page in the General Application Settings. These settings were previously located in the Project Web App (PWA) Server Settings page in Project Server 2010, but were moved to SharePoint Central Administration with other PWA settings that had more to do with server operations and maintenance. For more information about related administrative settings, see Queue and Database Administration (Project Server 2013). Requirements to access the Manage Queue Job settings in SharePoint Central Administration To access the Manage Queue Job settings in SharePoint Central Administration, you must be a farm administrator. Accessing the Manage Queue Job settings In Project Server 2013, the Manage Queue Job settings are now accessible through the SharePoint Central Administration site. To access the Manage Queue Job settings 1. In SharePoint Central Administration, click Application Management. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Manage Queue Jobs settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Manage Queue Jobs settings, and click Manage. 5. On the Project Server Settings page, in the Queue and Database Administration page, click Manage Queue Jobs. Use the Manage Queue Jobs settings The Manage Queue Jobs page lets you view, retry, or cancel jobs in the queue through the Jobs Grid. Viewable jobs are displayed according to the settings you select in the Manage Queue Jobs page. The configuration settings on the Manage Queue Job page include the following: Filter Type Job Types

257 Job Completion States Columns Advanced Options Filter Type The Filter Type configuration option lets you select filters to query for specific types of jobs that will appear in the Jobs Grid. The filters available in the Filter Type drop-down list are as follows: By Status Displays jobs in the queue in order by status. This is the default setting. My Jobs Displays only the jobs initiated by you. By Project Displays jobs in the queue in order by project. By ID Displays jobs in the queue in order by Job ID. Active Displays all jobs that have a status of Active. Blocked Displays all jobs that have a status of Blocked. To select a filter 1. On the Manage Queue Jobs page, in the Filter Type section, click the Filter Type drop-down list and select the type of filter that you want to use to determine which jobs appear in the Jobs Grid. 2. In the Jobs Grid, click Refresh Status. Jobs in the Jobs Grid appear according to the filter type that you select. For example, if you select the By Status filter, jobs are listed alphabetically by status. Job History This configuration option enables you to select the date range of jobs that appear in the Jobs Grid. Use the From and To fields to select a beginning and end data. The default selection is to select the one-day date range for the present date. You can use the Maximum Number of Jobs field to limit the number of jobs that appear for a given date range. If the selected date range contains a very large number of jobs that have to appear in the Jobs Grid, the load time for the Manage Queue Jobs page can be very long. The Maximum Number of Jobs field lets you limit the jobs that appear. The default setting is 500. To configure the Job History setting 1. On the Manage Queue Jobs page, in the Job History section, specify the following values: Job Types In the From field, specify the start date for which you want jobs to appear in the Jobs Grid. You can also click the calendar icon to select a start date. In the To field, specify the end date for which you want jobs to appear in the Jobs Grid. You can also click the calendar icon to select an end date. 2. In the Maximum number of jobs per queue box, you can specify the maximum number of jobs that you want to display. The default value is In the Jobs Grid, click Refresh Status. The Job Types configuration option lets you select the type of job (for example, Project Create, Timesheet Submit, Notifications, and so on) that you want to appear in the Jobs Grid. By default, all job types are listed in the Selected Jobs list.

258 To configure the Job Types setting 1. On the Manage Queue Jobs page, in the Job Types section: If you want to keep certain job types from appearing in the Jobs Grid, from the Selected Jobs list, select the job types that you do not want to appear in the Jobs Grid, and then click Remove. (This action moves the selected job types to the Available Jobs list.) Click Remove All if you want to remove all job types from the Selected Jobs list. If you want to add jobs types to the Jobs Grid, from the Available Jobs list, select the job types that you want to appear in the Jobs Grid, and then click Add. This action moves the selected job types to the Selected Jobs list. Click Add All if you want to add all job types to the Selected Jobs list. 2. In the Jobs Grid, click Refresh Status. Job Completion States The Job Completion States configuration option lets you select the job states (for example, Success, Blocked Due to a Failed Job, Processing, and so on) of the jobs that you want to appear in the Jobs Grid. By default, all job types except Success are listed in the Selected Jobs list, since Project administrators would be more interested in job types that signify a failure or blocking issue. You can add or remove different job states to and from the Selected Job States list and the Available Job States list. The Jobs Grid will query for jobs in the job stats listed in the Selected Job States list. This setting can be helpful for troubleshooting jobs that are not completing successfully in the queue. For example, some users might have experienced problems over the past several days. You can see specifically which jobs are not completing successfully by going to the Job Completion States setting and adding all job states except Success. You can also select a Job History date range that begins shortly before the problems occurred (for example, seven days). In this scenario, the Jobs Grid should display information about all jobs that are in a nonsuccessful job status that have occurred over the past week. The Job Completion states that you can select for this setting are as follows: Blocked Due to a Failed Job Cancelled Failed and Blocking Correlation Failed but not Blocking Correlation Getting Queued Processing Skipped for Optimization Success Waiting to be Processed Waiting to be Processed (On Hold) Waiting to be Processed (Ready for Launch) Waiting to be Processed (Sleeping) To configure the Job Completion States setting 1. On the Manage Queue Jobs page, in the Job Completion States section, add all job states that you want to display in the Jobs Grid to the Selected Job States list. Job states that are shown in the Available Job States list will not appear in the Job Grid.

259 Columns To move an available job state in the Available Job States list to the Selected Job States list, select the job and then click Add. To remove a job state from the Selected Job States list, select the job and then click Remove. To select multiple job states press the Ctrl key while making your selections. 2. In the Jobs Grid, click Refresh Status. The Columns configuration option lets you select the columns that appear in the Jobs Grid. It also lets you configure the order of the columns in the Jobs Grid. The column options available to you are as follows: % Complete Completed Time Correlation ID Correlation Priority Entry Time Error Job ID JobGroup ID JobInfo ID Job State Job Type Last Admin Action Owner Position Priority Project Name Queue Type Wait Time (secs) Wakeup Time To configure the Columns setting 1. On the Manage Queue Jobs page, in the Columns section, add all columns that you want to display in the Jobs Grid to the Selected Columns list. Columns that are shown in the Available Columns list will not appear in the Job Grid. To move a column in the Available Columns list to the Selected Columns list, select the column name and then click the Add button (">"). To remove a column from the Selected Columns list, select the column and then click the Remove button ("<"). To select multiple columns, press the Ctrl key while making your selections. You can also move all columns from one list to another by using the Add All (">>") or the Remove All ("<<")

260 buttons. 2. In the Jobs Grid, click Refresh Status. Note that you can change the order of the columns as they display in the Job Grid by selecting a column name in the Selected Columns list and using the Up or Down button to move the column to a different position. Advanced Options The Advanced Options queue setting applies to the way that jobs in the queue are canceled. The Cancel jobs getting enqueued option allows you to cancel all jobs that remain in a "getting enqueued" state for a prolonged time. When a job is in this state, it means that the queue has been told to start to receive a job that will be processed later. But it has not received a tag telling it that all the data for the job has been received. Until the full job has been received, the job will remain in the getting enqueued state. If a job remains in the getting enqueued state for a prolonged time, it is likely that something is preventing the job from finishing. If the job continues to remain in this state after you re-run it, review your ULS logs to troubleshoot why they problem is occurring. Saving a project from Project Professional to Project Server is a job that typically enqueues. When you save a project from Project Professional to the Project Server, the job synchronizes with the server. If the synchronization is not completed, then the job remains in the enqueued state. By default, this setting is enabled. Make sure to click Refresh Status in the Jobs Grid after you make any changes. NOTE In Project Server 2010, the Advanced Options page also contained an option to Cancel Subsequent Jobs in Correlation. This option is not available in Project Server Jobs Grid The Jobs Grid provides a view of the jobs that meet the criteria listed in the Manage Queue Jobs page. Options within this section let you select a job or group of jobs and to apply the following options to them, if applicable: Retry Job Allows you to rerun selected jobs in the queue that were not completed successfully. Cancel Job Allows you to cancel selected jobs in the queue that were not completed successfully. View Related Jobs Allows you to view jobs that have a dependency relationship (for example, jobs in the same correlation) with a selected job in the queue. Refresh Status Allows you to update the jobs in your job grid with the latest status. To retry a job 1. In the Jobs Grid, find the job that you want to retry, and then select the check box in the far left column of this job. 2. Click Retry Job. Recheck the status of the job in the Jobs Grid to verify the results of retrying the job. To cancel a job 1. In the Jobs Grid, find the job that you want to cancel, and then select the check box in the far left column of this job. Note that a job that has already completed successfully cannot be canceled. 2. Click Cancel Job. To view related jobs

261 1. In the Jobs Grid, find the job for which you want to find related jobs, and then select the check box in the far left column of this job. 2. Click View All Jobs. All jobs that have a dependency relationship with this job appear in the Jobs Grid.

262 Daily Schedule Backup (Project Server 2013) 12/18/ min to read Edit Online Summary: Use the Daily Schedule Backup settings page in SharePoint Central Administration to schedule daily backups of Project Server 2013 objects. Applies to: Project Server 2013 This article describes how to use the Daily Schedule Backup settings page to select the Project Server 2013 objects that you would like to schedule for back up on a daily basis. This procedure does not back up the physical files of a database (.mdb), but creates backups of specific items in the database. These items are backed up from the Published section to the Archive section in the Project Web App database. In order to access and use settings on the Daily Schedule Backup page, you must be a farm administrator. Items you can schedule for backup You can enable daily backup on the Daily Schedule Backup page for the following Project Server 2013 items: ITEM DESCRIPTION Project Enterprise resource pool and calendars Enterprise custom field Enterprise global template View definition Category and group settings Includes project resources, assignments, tasks, custom field values, baseline data Includes enterprise resources and enterprise calendars Includes enterprise custom field metadata, enterprise lookup table metadata, enterprise lookup table values Includes all Project Professional table, macro, and view definitions Includes statusing, Project Center, Portfolio Analyzer, and Resource Center view definitions Includes settings for all Project Server categories and groups. IMPORTANT Item-level backup and restore of category and group settings apply only in Project Permission Mode. For more information about security modes in Project Server 2013, see Plan user access in Project Server. To back up data automatically by using a daily schedule 1. In SharePoint Central Administration, click Application Management. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Administrative Backup settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want

263 to access the Daily Schedule Backup settings, and click Manage. 5. On the Project Web App Server Settings page, in the Queue and Database Administration section, click Daily Schedule Backup. 6. On the Daily Backup Schedule page, in the Project Retention Policy box, type the number of versions you want to retain for projects that you back up. NOTE The Project Retention Policy only pertains to projects and not to other enterprise objects. Also note that increasing this setting affects the Archive table in the Project Server 2013 database (ProjectService). The more versions you keep, the more space is required. 7. For each item in the Item section, select either Schedule or Never from the Option list to indicate whether you want to schedule a backup for that item. 8. Click Save. By default, all items you selected on the Daily Backup Schedule page are backed daily, at a time between 12 AM and 3 AM. As noted in the procedure, the number of versions that are backed up for projects depend on the value you set for the Project Retention Policy. All other items are only backed up to the previous version. NOTE If you do not want to schedule a daily backup, and need to make an immediate backup of these Project Server 2013 items, see Back up item-level objects through Administrative Backup (Project Server 2013). See also Back up item-level objects through Administrative Backup (Project Server 2013) Restore item-level objects through Administrative Restore (Project Server 2013)

264 Back up item-level objects through Administrative Backup (Project Server 2013) 12/18/ min to read Edit Online Summary: Use the Administrative Backup page in SharePoint Central Administration to back up Project Server 2013 objects. Applies to: Project Server 2013 This article describes how to back up specific project items in Project Web App. This procedure does not back up the physical files of a database (.mdb), but creates backups of specific items in the database. These items are backed up from the Published section to the Archive section in the Project Web App database. In order to perform these procedures, you must be a farm administrator. Backing up item-level objects You can use the procedures in this article to back up the following project items: ITEM DESCRIPTION Project Enterprise resource pool and calendars Enterprise custom field Enterprise global template View definition Category and group settings Includes project resources, assignments, tasks, custom field values, baseline data Includes enterprise resources and enterprise calendars Includes enterprise custom field metadata, enterprise lookup table metadata, enterprise lookup table values Includes all Project Professional table, macro, and view definitions Includes statusing, Project Center, Portfolio Analyzer, and Resource Center view definitions Includes settings for all Project Server categories and groups. IMPORTANT Item-level backup and restore of category and group settings only applies to Project Permission Mode. For more information about security modes in Project Server 2013, see Plan user access in Project Server. The following procedure allows you to select the Project Server 2013 items you would like to backup. When the procedure is completed, the backup job is immediately sent to the queue for processing. If you would like to schedule a daily backup of these items, this is done through the Daily Backup Schedule settings page. For more information on scheduling daily backups of Project Server 2013 items, see Daily Schedule Backup (Project Server 2013). To back up items manually 1. In SharePoint Central Administration, click Application Management.

265 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Administrative Backup settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Administrative Backup settings, and click Manage. 5. On the Project Web App Server Settings page, in the Queue and Database Administration section, click Administrative Backup. 6. In the Select Items section, select the check box next to each project item that you want to back up. 7. Click Backup. A message box will display telling you that the selected items will be queued for backup. Click OK to back up the selected items. When you backup projects for the first time, all projects are backed up. After the initial project backup, all subsequent project backups will only backup projects that have been updated since the last backup. This ensures that the latest version of the project is backed up for all projects. Note that you can configure the number of versions of a project that you would like to back up through the Project Retention Policy setting that is available in the Daily Schedule Backup page. The Project Retention policy pertains to both scheduled and manual administrative backups of projects. For more information about the Project Retention Policy setting, see Daily Schedule Backup (Project Server 2013). All Project Server 2013 items backed up through the Administrative Backup page can be restored through the Administrative Restore page. For more information about restoring backed up Project Server 2013 items, see Restore item-level objects through Administrative Restore (Project Server 2013). See also Restore item-level objects through Administrative Restore (Project Server 2013) Daily Schedule Backup (Project Server 2013)

266 Restore item-level objects through Administrative Restore (Project Server 2013) 12/18/ min to read Edit Online Summary: Use the Administrative Restore page in Central Administration to restore Project Server 2013 objects. Applies to: Project Server 2013 This article describes how to restore specific project items in Project Web App. This procedure does not restore the physical files of a database (.mdb), but restores backups of specific items in the database. These items were backed up to the Archive section of the Project Web App database through the Administrative Backup page in SharePoint Central Administration. For more information about item level-backup in Project Server 2013, see Back up itemlevel objects through Administrative Backup (Project Server 2013). Before you perform this procedure, confirm that project items have been backed up. In order to perform these procedures, you must be a farm administrator. Restoring item-level objects Use the procedure to restore the following project items: ITEM DESCRIPTION Project Enterprise resource pool and calendar Enterprise custom field Enterprise global template View definition Category and group settings Includes project resources, assignments, tasks, custom field values, baseline data Includes enterprise resources and enterprise calendars Includes enterprise custom field metadata, enterprise lookup table metadata, enterprise lookup table values Includes all Project Professional table, macro, and view definitions Includes statusing, Project Center, Portfolio Analyzer and Resource Center view definitions Includes settings for all Project Server categories and groups. IMPORTANT Item-level backup and restore of category and group settings are non-operational if you are using SharePoint Permission Mode. For more information about security modes in Project Server 2013, see Plan user access in Project Server. To restore project items by using Project Web App 1. In SharePoint Central Administration, click Application Management. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App

267 instance for which you want to access the Administrative Backup settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Administrative Restore settings, and click Manage. 5. On the Project Web App Server Settings page, in the Queue and Database Administration section, click Administrative Restore. 6. In the Item list, select the item that you want to restore. 7. If you selected Projects from the Item list, select the version of the project that you want to restore as the current working version of the project. NOTE The versions that are available for you to restore depend upon the number of backups that have been completed and the total number of backups that you have chosen to retain. 8. Click Restore. 9. Any changes that were made between when the item was deleted and when the item was most recently backed up cannot be restored. See also Back up item-level objects through Administrative Backup (Project Server 2013) Queue and Database Administration (Project Server 2013)

268 Periodic tasks for Project Server administrators 12/13/ min to read Edit Online Applies to: Project Server 2016, Project Server 2013 This article describes periodic checks Project Server admins should perform to maintain their environments. It was contributed by Microsoft Senior Premier Field Engineer Brooks White. Project Server administrators should perform the following periodic checks to their environment as an important part of their job: DAILY Check the queue for Failed and Blocking jobs. Review the errors related to Failed and Blocking jobs to troubleshoot. Check for nightly cube build failures. Cancel Failed and Blocking jobs. WEEKLY Review application and event logs on web front end (WFE) servers, APP servers and the SQL Server. Use the Unified Logging Service (ULS logs) as needed, based on the finding in the application and system event logs. Use the Merge-SPLogFile PowerShell cmdlet to filter output from all servers. Check Active Directory synchronization jobs to ensure they were successful. Update Resource Breakdown Structure (RBS) values for new users. Newly synched users won't have an RBS. NOTE - This may be the job of the PMO. Clear any overly long delegation sessions in Server Settings Maintain a valid enterprise resource pool by checking for users who haven't logged in for 60 days and find out why. For example, they may have left the company, are unaware of PWA, or could have been added mistakenly when someone else needed access. Check the ADMINISTRATORS group for admins that should be removed. MONTHLY Provide timesheet training to new users. Provide project manager training to new project managers.

269 QUARTERLY Close timesheet periods for the previous quarter plus one or some similar period. For example, if you are in Q4, close the timesheet reporting periods for Q2. The interval will be based on business or reporting needs. Check with the project manager first, then close tasks to updates on projects that are complete or mostly compete or that have older tasks. Archive and delete projects/sites for old completed project plans. But first create an archive plan that is documented and adhered to. > [!NOTE]> Generally speaking, don't ever delete any resources from Server Settings Delete timesheets from the past. Again, this will be defined by a policy that is based on business needs for reporting timesheet data. YEARLY Create fiscal periods for the next calendar year. Create timesheet periods for the next calendar year. The prefix might equal "Week.", starting at 1, and the suffix might be the calendar year, such as ".2016". Week 1's period will show as "Week ". Consider deleting timesheets for long-ago periods.

270 Exchange Server calendar OOF integration with Project Server /13/ min to read Edit Online Summary: In Project Server 2013, you can synchronize Project Resource Calendars to Exchange Server calendars to retrieve and synchronize users' out-of-office time. Then, when users update this information in Exchange, Project is aware of it. Applies to: Project Server 2013 This is an on-premises feature for Project Server It is not supported on Office 365. Enable Project Server 2013 and Exchange Server OOF calendar integration By default, this feature is disabled and must be enabled in your SharePoint Server 2013 environment by someone with Farm Administrator privileges. Note Time reporting periods must be configured for Exchange Server OOF calendar integration to work. To enable this feature in Central Administration 1. Using an account that has farm administrator credentials, log on to an instance of SharePoint Server in your farm that is running Central Administration. 2. Go to Start > Run > All Programs > SharePoint Products and Technologies > SharePoint 2016 Central Administration, and choose this option to open Central Administration. 3. On the main Central Administration page, click General Application Settings on the left side. 4. On the General Application Settings page, click the Manage link in the PWA Settings section. 5. If you have more than one PWA instance, make sure that the correct Project Web Application Instance is displayed on the upper-right side of the page. If it is not, select the drop-down arrow and then click Change Project Web App Instance to allow you to select the correct instance. 6. With the correct instance selected, click the Additional Server Settings link in the Operational Policies section. 7. On the following page, scroll down to the Exchange Server Details section, near the bottom of the page. This section contains a single check box for Synchronize Out of Office calendars. Select that check box, and then click Save. Once this feature is enabled at the Central Administration level, a Project Web Access administrator must enable it for individual resources at the PWA level. To enable Project Server 2013 and Exchange Server OOF calendar integration for individual resources 1. Log on to a computer as the PWA Administrator, and then browse to the PWA site that has Exchange Server synchronization enabled on it. 2. Click the Resources link on the left-hand side of the main page.

271 3. Once the resources are displayed, you can select a resource with a valid Exchange Server address and then click the Edit button from the Resources tab. 4. On the Edit Resource: [USER] page, scroll down and locate the Exchange Server Details section, which has a Synchronize Out of Office calendars check box, similar to the Central Administration section discussed earlier. 5. As in Central Administration, this check box must be checked for the user, and then the Save button at the bottom of the page should be clicked. Note Repeat this procedure for each resource in your PWA resource list that should have this functionality. Bulk edit does not give you this option to select for multiple users at the same time. You can adjust the Exchange sync timer job. By default, it will run once per day, and be scheduled for off-peak hours during the night. A farm administrator can change the frequency or time by modifying this job. To change the Exchange sync timer job 1. Log on to an instance of SharePoint Server in your farm that is running Central Administration by using an account that has farm administrator credentials. 2. Go to Start > Run > All Programs > SharePoint Products and Technologies > SharePoint 2013 Central Administration, and choose this option to open Central Administration. 3. On the main Central Administration page, click the Monitoring link on the left side. 4. On the Monitoring page, click the Review job definitions link in the Timer Jobs section. 5. You must locate the Project Web App: Exchange Calendar Out of Office synchronization job for [PWA URL] timer job, where [PWA-URL] is the URL of the PWA site you've enabled the feature on. Click this timer job link. 6. On the Edit Timer Job page, you can make the changes that you must have, such as running the job at a time other than the early morning hours, or changing to be more frequent, such as hourly. For more information on timer jobs, see Timer job reference. Effect of OOF integration for users and project managers With this feature enabled, users will be able to enter their OOF time in Exchange via Outlook or Outlook Web Access and that information will then become visible in their Project Server timesheet. All scheduled out-of-office time, whether a complete day or partial day, is displayed as unavailable on a resource calendar for a Project Manager. From the Project Manager's perspective, no work has to be done. Users who submit their out-of-office time in Exchange Server are now accounted for. This enables Project planning to be more accurate. How Exchange Server OOF calendar integration with Project Server 2013 works The synchronization between Project Server and Exchange Server is triggered from Project Server. This happens when a user account is enabled or through scheduled timer jobs. After the procedure starts, Exchange Server is contacted for free/busy information for the user or users specified.

272 If a resource is unavailable for editing because it has been checked out, that user is bypassed as part of the sync operation and will be synchronized the next time that the timer job is run. Although users may not want to enter their vacation and out-of-office time in multiple places, this calendar integration feature is probably not going to replace timesheets, because they are necessary for billing and other line-of-business purposes. To support this scenario, OOF time synchronized from Exchange Server is displayed as non-working time in the user's timesheet, consistent with how non-working time is currently shown in the user's timesheet. This indicates to the user that the time is already blocked off from another source, but it does not prevent him or her from entering time for that day. A new addition to Exchange Server 2013 and Outlook 2013 is the 'working from elsewhere' time scheduling option. This option should not be reflected in imports, as the decision was made to respect traditional outof-office/nonworking options for backward compatibility with product versions that do not have that enum type. Time data is imported from Exchange Server at 15-minute intervals and aggregated to determine the total effect that the imported OOF time should have on the resource calendar. If the total out-of-office hours for a given day are less than four hours, then the out-of-office time is not reflected on Resource calendars. Amounts of four hours or more will be reflected. As both a user's Exchange Server and Project Server resource calendars have working hours and nonworking hours defined. Therefore, out of hours from the Exchange Server calendar that are within the Exchange Server working time period will count toward the number of hours taken from working time in Project Server. If the whole day is defined as non-working in Exchange Server, the whole day will also be specified as non-working in Project Server.

273 Use Project Server 12/13/ min to read Edit Online Summary: How to use server settings in Project Web App to administer an installation of Project Server. The following articles about how admins can use the Project Server server settings are available to view online: Manage users, groups, and categories in Project Server Enterprise custom fields and lookup tables in Project Web App Database administration in Project Server Operational Policies in Project Server 2013 Add SharePoint task list data to Project Server 2013 Project Server 2013 Administrator's Guide

274 Project Server 2013 Administrator's Guide 12/13/ min to read Edit Online Summary: Download and use the Microsoft Project Server 2013 Administrator's Guide to manage and administer Project Server 2013 in your organization. Applies to: Project Server 2013 Project Server 2013 administrators must manage many tasks in the Project Web App (PWA) Server Settings page for users to access and interact effectively with data. Farm administrators must also understand the tasks in the PWA Server Settings that they might be responsible for, such as OLAP database management, queue settings management, or project site provisioning settings. The Microsoft Project Server 2013 Administrator's Guide helps your organization understand these tasks that are involved with administering Project Server It includes many step-by-step procedures and accompanying user-interface screen shots of Project Web App. File size: approximately 7.1 MB Download the guide as a.docx file Changes in Project Server 2013 that affect administration Before reading through this guide, it is important to know of several key changes in Project Server 2013 that make administration different from the previous versions. These changes include the following: Some server settings moved to Central Administration: A few Project Web App Server Settings that have previously been located in Project Web App in Project Server 2010 were moved to Central Administration in Project Server The reason for this change was that these settings were tasks that were more typically done by a farm administrator, instead of a PMO manager or Project Server 2013 administrator. SharePoint Permissions Mode: By default, Project Server 2013 security will be in SharePoint Permissions Mode. This mode uses Project Server 2013 SharePoint Security groups as containers in which Project Server 2013 can be added as members. Project Server 2013 permissions are assigned to these group, and they are not editable. If you must have more control, you can change to the traditional Project Server Permissions Mode. It is important to understand security modes when you are viewing the "Security" chapter. Project Online: Project Online is a hosted version of Project Server 2013 in which the service is hosted in the cloud. Administration will be different for Project Online and Project Server 2013, because many administrative tasks are performed for you and are inaccessible to users. The tasks documented in this guide are intended for Project Server 2013 users, and not for Project Online users. A Project Online Administrators Guide will be available to you at a later date. Book structure This guide is divided into two sections, because Project Server 2013 administrative settings are now located in Project Web App and in Central Administration. The "Project Web App Settings in Project Server 2013" section contains eight chapters and is targeted to the Project Server Administrator or PMO. The "Project Web App Settings in SharePoint Central Administration" section is made up of four chapters and contains information that is of more interest to your farm administrator. Both sections are organized in the same manner in this book as they are organized in Project Web App and in Central Administration. This guide also contains appendix data, which is primarily reference data and lists. Note that all of the chapters in the "Project Web App Settings in SharePoint Central Administration" section will

275 also have similar chapter titles as the chapters located in the "Project Web App Settings in Project Server 2013" section of the book. This is because tasks associated with the chapter title are located in the PWA Settings page of both Project Server 2013 and Central Administration. For example, all "Operational Policies" tasks that typically are performed by a farm administrator are located in Central Administration, and all "Operational Policies" tasks that are typically done by a Project Server 2013 administrator are located in Project Server The Microsoft Project Server 2013 Administrator's Guide contains the following chapters and appendices: Introduction Part 1: Project Web App Settings in Project Server Chapter 1, "Personal Settings" - Chapter 2, "Enterprise Data" - Chapter 3, "Queue and Database Administration" - Chapter 4, "Look and Feel" - Chapter 5, "Time and Task Management" - Chapter 6, "Operational Policies" - Chapter 7, "Workflow and Project Detail Pages" - Chapter 8, "Security" Part 2: Project Web App Settings in SharePoint Central Administration - Chapter 9, "Queue and Database Administration" - Chapter 10, "Operational Policies" - Chapter 11, "Workflow and Project Detail Pages" - Chapter 12, "Manage Queue Settings" Appendices - Appendix A, "Project Server 2013 Category Permissions" - Appendix B, "Project Server 2013 Global Permissions" - Appendix C, "Project Server 2013 Default Security Groups" - Appendix D, "Project Server 2013 Default Categories" - Appendix E, "SharePoint Permission Mode Default Permissions for Project Server 2013 SharePoint groups"

276 Manage users, groups, and categories in Project Server 12/18/ min to read Edit Online Summary: Manage users, groups, and categories in Project Server permission mode. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, Project Web App security is based on users, groups, and categories. Groups contain sets of users who need to access the same set of data in the same way. Categories provide access to projects and resources based on parameters that you define. For complete information about planning groups and categories, see Plan groups, categories, and RBS in Project Server. Define your groups by identifying common needs based on the areas of Project Web App to which users in your organization need access. After you define your groups, you can add users to the groups and grant permissions to the groups. Permissions assigned to groups apply to all of the users that the group contains. Using groups to control access to Project Web App simplifies security administration. Users can be automatically added or removed from groups based on Active Directory group membership. This can be configured in Project Web App through the Active Directory synchronization feature. For more information, see Manage security group synchronization with Active Directory in Project Server. Users can belong to multiple groups according to their role in the organization and their access requirements. Several groups are created by default when a Project Web App instance is created, each of which is assigned a set of predefined categories and permissions. For more information, see Manage security groups in Project Server. Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group. For complete lists of Project Web App permissions in Project Server 2013, see Category permissions in Project Server 2013 and Global permissions in Project Server Articles about Security settings for Project Server permission mode The following are the tasks for managing security in Project Server permission mode: CONTENT Manage users in Project Server Manage security groups in Project Server Manage categories in Project Server DESCRIPTION Use the Manage Users page in Project Web App to add, modify, deactivate, and reactivate user accounts. Administrators can manage security permissions for groups by using the Manage Groups page in Project Web App Settings. Administrators can organize a system of categories to manage user and group access to projects, resources, and views in Project Web App.

277 CONTENT Manage security templates in Project Server Manage Project Web App permissions (Project Server permission mode) Manage delegates in Project Server Manage security group synchronization with Active Directory in Project Server Plan users, groups, and catagories in Project Web App DESCRIPTION Administrators can use security templates in Project Web App to standardize the granting of user permissions by role. Project Web App global and category permissions can be disabled, but this action should be examined carefully before it is done. Project Server 2016 enables user delegation throughout all of Project Web App. Project Server security group synchronization controls Project Server security group membership by automatically adding and removing users from specified Project Server security groups based on group membership in the Active Directory directory service. This article addresses planning for groups and categories in a Project Server deployment. Videos about Security settings for Project Server Video series: How security permissions work in Project Server

278 Manage users in Project Server 12/13/ min to read Edit Online Summary: Use the Manage Users page to add, modify, deactivate, and reactivate user accounts. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, you can use the Manage Users page that is available in Project Web App Settings to add new individual users, modify existing users, deactivate user accounts, and reactivate inactive user accounts. You can also assign permissions to users by adding them to one of the built-in groups or by adding them to a custom group that you created, and assigning specific permissions to the custom group. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Task requirements The following are required to perform the procedures for this task: Access to Project Server through a Project Web App site The Manage users and groups global permission in order to add, modify, deactivate, or reactivate a user account To manage users in Project Web App, you can perform the following procedures: Add user accounts in Project Server Modify user accounts in Project Server Deactivate user accounts in Project Server Reactivate a user account in Project Server See also Determine the number and types of users that require access to Project Server 2016 Manage users, groups, and categories in Project Server Global permissions in Project Server 2013 Category permissions in Project Server 2013 Manage security groups in Project Server Manage categories in Project Server Manage security templates in Project Server Manage Project Web App permissions (Project Server permission mode)

279 Add user accounts in Project Server 12/14/ min to read Edit Online Summary: Add user accounts by using the Manage Users page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 Every Project Web App user must have a user account before he or she can log on to Project Web App and interact with Project Server data. In Project Server permission mode, user accounts can be added through the Manage Users page in Project Web App Settings. Note Windows users can also be added to Project Web App from the Active Directory directory service through Active Directory Synchronization. For more information, see Manage Active Directory Resource Pool synchronization in Project Server Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> For SharePoint Server 2013:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch> For SharePoint Server 2016:> Software requirements for Project Server 2016> Accessibility for SharePoint Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage users in Project Server. You must have access to the Project Web App instance where you want to add a user. The user accounts that you are adding are configured properly in either Active Directory or the forms-based membership provider so that their information is available to Project Web App. Project Server 2016 supports two authentication methods for its users (Windows authentication and claims authentication). Important The Manage users and groups global permission in Project Web App is required to complete this procedure. To add a new user account, perform the following procedure. To add a user

280 1. On the Server Settings page, in the Security section, click Manage Users. 2. On the Manage Users page, click New User. 3. On the New User page, fill out the required information for the user. See the following sections for more information about each option. 4. Click Save. Identification Information Use the Identification Information section to specify user information such as name, address, and account status. The following table describes the user identification options. ATTRIBUTE User can be assigned as a resource Display Name address RBS Initials Hyperlink Name Account Status DESCRIPTION The status of the user as an Enterprise Resource. Select User can be assigned as a resource to enable this user account to be assigned tasks as a resource. Selecting this entry makes the user an Enterprise Resource. This setting is the default selection. Once a user account becomes an Enterprise Resource it cannot be changed back to a non-enterprise Resource even if the check box is cleared. The name for the user account. This is a required field. The address for the user. This field is required to synchronize tasks with Exchange Server. The user's position in the Resource Breakdown Structure hierarchy. The user's initials. The name of the user's web site (for example, a team web site) if applicable. Can be set to Active or Inactive. If the value is set to Active, the user account functions normally. If the value is set to Inactive, the user is unable to access the account and they are no longer available for adding to teams or being assigned to work, but their existing assignments remain in Project Web App. User Authentication Use the User Authentication section to specify the user's logon account. The following table describes the user account options. ATTRIBUTE DESCRIPTION

281 ATTRIBUTE User logon account DESCRIPTION If you are using Integrated Windows authentication, type the user's account name in the form of DomainName\UserAccountName. If you are using Project Online, type the user's account name in the form of If you are using forms-based authentication, type the user account name in the form of MembershipProviderName:UserAccount. Assignment Attributes Use the Assignment Attributes section to define information associated with the user's assignment to tasks. This includes calendar, booking type, timesheet manager, assignment owner, and cost and availability information. Note If you have not selected the User can be assigned as a resource check box, these options are not available. The following table describes the Project Web App user assignment attribute options. ATTRIBUTE Resource can be leveled Base Calendar Default Booking Type Timesheet manager Default Assignment Owner Earliest Available DESCRIPTION Indicates whether the resource can be leveled. Leveling is the process that is used to resolve resource conflicts or overallocations by delaying or splitting certain tasks. When Project Web App levels a resource, its selected assignments are distributed and rescheduled. The base calendar for this resource. A base calendar is a calendar that can be used as a project and task calendar that specifies default working and non-working time for a set of resources. The configuration of a user's booking type as either Committed or Proposed. A committed resource is formally allocated to any task assignment in a project. A proposed resource has a pending resource allocation to a task assignment that has not yet been authorized. This resource assignment does not detract from the availability of the resource to work on other projects. The timesheet manager, if there is one, for the user. If you set this value to this user, all submitted timesheets will be automatically approved. The enterprise resource who is responsible for entering progress information in Project Web App. This person can differ from the person first assigned to the task. For example, a material resource cannot log on to Project Web App but the assignment owner field allows an enterprise resource to enter progress for the resource within Project Web App. The earliest date that the user is available as a resource. This date corresponds to the resource availability dates for a resource that can be seen in Project Professional 2016.

282 ATTRIBUTE Latest Available Standard Rate Overtime Rate Current Max. Units (%) Cost/Use DESCRIPTION The latest date that the user is available as a resource. This date corresponds to the resource availability dates for a resource that can be seen in Project Professional The rate for the work on an assignment that is scheduled during the regular working hours of an assigned resource. To establish variable rates, open the enterprise resource in Project Professional 2016 and set this information in the Cost Rate tables. The rate for the work on an assignment that is scheduled beyond the regular working hours of an assigned resource. To establish variable rates, open the enterprise resource in Project Professional 2016 and set this information in the Cost Rate tables. The percentage of time that the resource is available for assignments. The current max units is tied to the early and late availability dates, if set. For example, if today is 1/1/2012 and the earliest available date is 1/2/2012 then the max units value is 0% and text next to the field says "Custom availability detected, edit in Project Professional 2016." The per-use cost of the resource if applicable. For work resources, a per-use cost accrues every time that the resource is used. For material resources, a per-use cost is accrued only one time. Exchange Server Details Use the Exchange Server Details section to specify Exchange Server settings for the user. Select the Synchronize Tasks check box if you want to enable task synchronization by using Microsoft Exchange Server for this user. Exchange integration must be configured for task synchronization to function. Select the Synchronize Out of Office Events check box if you want to enable synchronization of the user's out of office information from Exchange Server to their Project Web App resource calendar as non-working time. Departments Use the Departments section to define whether the user is a member of a particular department. (You define departments for your organization by populating the Departments custom lookup table.) If the user is a member of a department, click the expand button ( ) and select the department from the displayed hierarchy. Security Groups Use the Security Groups section to specify the user's membership in security groups. To add the user to a security group, select the group in the Available Groups list, and then click Add. The following table describes the security group configuration options for a user.

283 ATTRIBUTE Available Groups Groups that contain this user DESCRIPTION The Available Groups list contains the groups that the user is currently not a member of. The Groups that contain this user list contains the groups that the user is currently a member of. Security Categories Use the Security Categories section to specify the user's membership in security categories. To add the user to a category, select the category in the Available Categories list, and then click Add. To modify the category permissions for this user in a category, select the category in the Selected Categories list, and then select Allow for the permissions that you want to enable. Important We recommend that you do not set category permissions for a single user. Instead, assign the user to a group and set category permission for the group. This allows for easier maintenance. The following table describes the security category configuration options for a user. ATTRIBUTE Available Categories Selected Categories Permissions for Set permissions with Template DESCRIPTION The Available Categories list contains the categories that the user is not a member of. The Selected Categories list contains the categories that the user is a member of. The Permissions for area lets you configure category permissions for this user for the selected category. The Set permissions with Template option can be used to prepopulate a set of category permissions based on a predefined template for the user's role (such as Portfolio Viewer or Project Manager). Global Permissions Use the Global Permissions section to configure global permissions for the user. To allow or deny a global permission for the user, select the Allow or Deny check box for the permission. We recommend that you do not configure global permission for a single user. Instead, configure permissions at the group level and add users to the appropriate group. Doing this allows for much easier administration and helps in troubleshooting permissions issues. For a complete list of global permissions for Project Server 2013, see Global permissions in Project Server Group Fields Use the Group Fields section to define group and cost information for the user. Group fields are not tied to Project Web App security, but are a way to specify that a user belongs to a particular group in your organization. These

284 fields appear in the Project Web App database and can be used for reporting. Cost Type can be added to the resource and assignment OLAP cubes. If your organization uses group names, codes, or cost center information for people, type the information in the Group Fields area. The values available for Cost Type are those that are defined in the Cost Type custom lookup table. By default, the Group field is synchronized with Active Directory if you use Active Directory synchronization. Team Details Use the Team Details section to define a team association for the user. To use teams, you must first do the following: 1. Create a custom lookup table and populate it with the team names that you want to use. 2. Edit the Team Name custom field to use the new lookup table. You can use teams to pool assignments under a single resource where they can be later reassigned to other resources. For example, you could create a team resource named "Development" to which you assign software development tasks. By assigning this resource to the Development team and selecting the Team Assignment Pool check box, you enable other users on the Development team to see any tasks assigned to the Development resource and to accept the assignments in Project Web App. You could also select Team Assignment Pool for a team lead and have all assignments go through that person for distribution to team members. System Identification Data The System Identification Data section displays user metadata, such as when the account was created, updated, or checked out. In the System Identification Data section, type additional identifying information for the user in the External ID box. This information can be used to link the person to corresponding information elsewhere in the organization, or to facilitate the consolidation of reporting of resource use beyond what Project Server provides. The following table describes the system identification data fields. ATTRIBUTE GUID External ID Active Directory GUID Date Created Date last updated Checked out by Checkout date DESCRIPTION The unique ID associated with this user. An identifier that can be used to link this user to external data. The unique ID for this user's Active Directory account. The date this user account was created. The date this user account was last updated. The user who currently has this user account checked out. The date this user account was checked out. See also Manage users in Project Server Modify user accounts in Project Server

285 Manage security group synchronization with Active Directory in Project Server

286 Modify user accounts in Project Server 12/13/ min to read Edit Online Summary: Edit user accounts by using the Manage Users page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, you can modify existing account information for any user. You might want to do this, for example, if a resource name is changed or if a resource changes roles in your organization. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server 2016 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server 2016 supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage users in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Modify a user account Use this procedure to modify an existing Project Web App user account. To modify a user account 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Users. 3. On the Manage Users page, in the Users list, click the name of the user that you want to edit. 4. On the Edit User page for the selected user, make your changes to the user account information. For information about each option on the page, see Add user accounts in Project Server. 5. Click Save. See also

287 Manage users in Project Server Add user accounts in Project Server Manage Active Directory Resource Pool synchronization in Project Server 2013

288 Deactivate user accounts in Project Server 12/13/ min to read Edit Online Summary: Deactivate user accounts by using the Manage Users page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 At times, you may have to make Project Web App user accounts unavailable. In Project Server permission mode, when you deactivate a user account, that user's information and data remains in the database, but the user is unavailable for new assignments. The user account is inactive until it is reactivated. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Deactivating a user account means that it can no longer be used to log on to Project Web App. Users cannot use this account to send assignment updates, request status reports, or delegate tasks. Once a user is deactivated, the Project Manager is prompted to reassign the user's work. This prompt occurs when the Project Manager opens the project in Project Professional. User accounts, when deactivated, are not actually deleted from the Project Web App database. This is to ensure that any relationships that resource might have with project data can be preserved in case the account is reactivated later. The option to delete a user is available in the Database Administration section in Project Web App Settings. However, deactivating a user to preserve data is recommended. After an account is deactivated, the account cannot access Project Web App until it has been reactivated. The Manage users and groups global permission in Project Web App is required to complete this procedure. When you are using Active Directory synchronization, Project Web App users not found in the Active Directory group being synchronized will be deactivated. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage users in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure.

289 Deactivate a user account Use this procedure to deactivate an active Project Web App user account. After this procedure has been performed, the account will be unable to access Project Web App until it has been reactivated. To deactivate a user account 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Users. 3. On the Manage Users page, in the Users list, find the user account that you want to deactivate. (You can use the Search box to search for a specific user.) Click the check box next to the user name of the account that you want to deactivate. Note that you can select multiple user accounts. 4. Click Deactivate Users. 5. A message box appears and asks for confirmation. Click OK to deactivate the user account or user accounts. See also Reactivate a user account in Project Server Manage Active Directory Resource Pool synchronization in Project Server 2013

290 Reactivate a user account in Project Server 12/13/ min to read Edit Online Summary: Reactivate deactivated user accounts by using the Manage Users page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 After you deactivate a user account, you may need to reactivate it at some later time. Because the user information still exists in the Project Server database, you simply need to change the account status from Inactive to Active. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage users in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Reactivate a user account Use this procedure to reactivate a deactivated Project Web App user account. After you have performed this procedure, the reactivated account is able to access Project Web App. To reactivate a user account 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Users. 3. On the Manage Users page, in the Users list, find the user account you want to reactivate. (You can use the Search box to search for a specific user.) Click the user name of the account. 4. On the Edit User page for the selected user, in the Identification Information section, select Active from the Account Status drop-down list. 5. Click Save. See also Deactivate user accounts in Project Server Manage Active Directory Resource Pool synchronization in Project Server 2013

291 Manage security groups in Project Server 12/13/ min to read Edit Online Summary: Administrators can manage security permissions for groups by using the Manage Groups page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 A group is a container for users that can be assigned permissions in Project Web App. Users automatically inherit the permissions of any group to which they belong. By adding users to groups, you can significantly reduce the amount of time spent managing user permissions. In Project Server permission mode, you can manage groups from the Project Web App Server Settings page. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Avoid creating unnecessary groups. Having lots of groups and categories in an organization can lead to additional management complexity. Additionally, having many groups and categories can stress the authorization system, which can affect performance. You can modify the information associated with any security group in Project Web App. For example, you may have to modify the group for changes to users or categories, or for changes to the Active Directory group to which it is currently being synchronized. We recommend not modifying the default Project Web App groups, but instead creating a new group that has the same permissions and modifying the new group. By default, the following groups are available in a Project Web App running in Project Server permission mode: Team Members Users have general permissions for using Project Web App, but limited project-level permissions. This group is intended to give everyone basic access to Project Web App. All new users are added to the Team Members group automatically. This group is associated with the My Tasks category. Project Managers Users have most global and category-level project permissions and limited resource permissions. This group is intended for users who maintain project schedules daily. This group is associated with the My Organization and My Projects categories. Resource Managers Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data. This group is associated with the My Direct Reports, My Organization, My Projects, and My Resources categories. Portfolio Viewers Users have permissions to view project and Project Web App data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks. This group is associated with the My Organization category. Team Leads Users have limited permissions around task creation and status reports. This group is intended for people in a lead capacity who do not have regular assignments on a project. This group is associated with the My Projects category. Portfolio Managers Users can create and edit data, but cannot perform Project Web App administrative tasks such as adding users or creating groups. Portfolio Managers are able to view and edit all projects and

292 resources in the organization. This group is associated with the My Organization category. Administrators This group is granted all available Project Web App permissions. It is associated with the My Organization category. These default groups should be used together with the five default categories. Task requirements The following are required to perform the procedures for this task: Access to Project Web App The Manage users and groups global permission in Project Web App in order to add, modify, or delete a group To manage groups in Project Web App, you can perform the following procedures: Create security groups in Project Server Modify security groups in Project Server Delete a security group (Project Server permission mode) See also Manage users, groups, and categories in Project Server Category permissions in Project Server 2013 Global permissions in Project Server 2013 Plan groups, categories, and RBS in Project Server

293 Create security groups in Project Server 12/14/ min to read Edit Online Summary: Create custom security groups by using the Manage Groups page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 Seven default security groups are available in Project Web App in Project Server permission mode. To better meet the security requirements of your own organization, you can also create custom groups by using the Manage Groups page on the Project Web App Server Settings page. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage security groups in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Perform the following procedure to create a custom group in Project Web App. To create a security group 1. On the Server Settings page, in the Security section, click Manage Groups. 2. On the Manage Groups page, click New Group. 3. Complete the required fields on the Add or Edit Group page. See the following sections for information about each area. 4. Click Save. Group information Use the Group Information section to specify a name and description for the group.

294 The following table describes the group information options. ATTRIBUTE Group Name Description DESCRIPTION The name of the group A description of the group Active Directory Group If you want to synchronize the membership of this group with an Active Directory group, type the name of the Active Directory group in the format domain\group. To stop synchronizing an existing group, click the X next to the group. Users Use the Users section to specify which Project Web App users are members of this group. To add users to the group, select the users in the Available Users list, and then click Add. To remove users from the group, select the users in the Selected Users list, and then click Remove. If you have configured Active Directory synchronization for this group, the group membership is maintained by that mechanism. Any changes that you make manually may be overwritten the next time that the group is synchronized with the Active Directory directory service. The following table describes the options for users in the group. ATTRIBUTE Available Users Selected Users DESCRIPTION The users in Project Web App that are not members of this group The users in Project Web App that are members of this group Categories Use the Categories section to define which security categories area associated with this group. To associate a category with this group, select the category in the Available Categories list, and then click Add. To set the category-level permissions for a particular category, select the category in the Selected Categories list, and then click Allow for the permissions that you want to enable for this category/group combination. The following table describes the categories options for a group. ATTRIBUTE Available Categories Selected Categories Permissions for DESCRIPTION The categories that are not associated with this group. The categories that are associated with this group. The permissions that members of this group have within the selected category. This option appears when you select a category in the Available Categories list.

295 ATTRIBUTE Set permissions with Template DESCRIPTION To set the category permissions for the selected category from a template such as Project Manager or Team Member select the desired template from the list, and then click Apply. Global permissions Use the Global Permissions section to configure global permissions for this group. To allow a permission for the group, select the Allow check box for that permission. To deny a permission for the group, select the Deny check box for that permission. To set the global permissions from a template, select the template from the Set permissions with Template dropdown list, and then click Apply. For a complete list of global permissions in Project Server 2013, see Global permissions in Project Server Note If neither check box is selected for a permission, the user is not allowed the permission unless it is allowed in another group that the user is a member of, or it is allowed at the user level. If the Deny check box is selected for a permission, that permission is denied for all users in the group and cannot be enabled through other group or user settings. See also Plan groups, categories, and RBS in Project Server Global permissions in Project Server 2013 Manage security groups in Project Server

296 Modify security groups in Project Server 12/13/ min to read Edit Online Summary: Change settings for security groups by using the Manage Groups page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, you can modify the information associated with any security group in Project Web App. For example, you may have to modify the group for changes to users or categories, or for changes to the Active Directory group to which it is currently being synchronized. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage security groups in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Modify a security group Perform the following procedure to modify an existing group in Project Web App. To modify a group 1. On the Project Web App home page, on the Settings menu, click Server Settings. 2. On the Server Settings page, in the Security section, click Manage Groups. 3. On the Manage Groups page, in the Group Name list, click the name of the group that you want to modify. 4. On the Add or Edit Group page for the selected group, make your changes to the group information. For information about each option on the page, see Create security groups in Project Server. 5. Click Save.

297 See also Manage security groups in Project Server

298 Delete a security group (Project Server permission mode) 12/13/ min to read Edit Online Summary: Delete custom security groups by using the Manage Groups page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, if you no longer need a security group in Project Web App, you can delete it. Before you delete a group, ensure that no other users or groups are dependent on it for required permissions. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage users in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Delete a security group Perform the following procedure to delete a group in Project Web App. Important We highly recommend that you not delete the default Project Web App groups. The Team Members group cannot be deleted. To delete a custom group 1. On the Project Web App home page, on the Settings menu, click Server Settings. 2. On the Server Settings page, in the Security section, click Manage Groups.

299 3. On the Manage Groups page, in the Group Name list, find the group you want to delete. Select the check box next to the group that you want to delete. Note that you can select multiple groups. 4. Click Delete Group. 5. A message box appears, asking for confirmation and noting that the group will be permanently removed. Click OK to delete the group. Note Security groups are permanently deleted, unlike deactivated user accounts (which can be reactivated). If you delete a security group and then find that you want to have it again, you must recreate it. See also Manage users in Project Server

300 Manage categories in Project Server 12/13/ min to read Edit Online Summary: Administrators can organize a system of categories to manage user and group access to projects, resources, and views in Project Web App. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, Categories are the collections of projects, resources, and views to which users and groups in Project Server are granted access. Categories define which collections of specific data (projects, resources, and views) that these users and groups have access to. Categories also allow the administrator to filter data using security rules, like Resource Breakdown Structure (RBS), that can help organize and display data in specific ways. Note Categories are only available in Project Server permission mode. If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. You can add projects and resources to categories manually by choosing them from lists, or you can use dynamic filters to automatically add them to categories. Any user associated with a category can be granted permission to the projects and resources in that category. You must have the Manage users and groups global permission to add, modify, or delete a category. Avoid creating unnecessary categories. Having a large number of groups and categories within an organization can stress the authorization system, which can affect performance. Project Web App provides five default categories in Project Server permission mode. These default categories are designed to enable Project Web App to provide the most common layer of security for a hierarchical organization or matrix organization. DEFAULT CATEGORY DEFAULT GROUPS IN THE CATEGORY DESCRIPTION My Tasks Team Members Primarily used by project resources who have assigned tasks. My Projects Project Managers Resource Managers Team Leads Provides access to all projects that a user owns. My Resources Resource Managers Intended for resource managers and is useful only after the Resource Breakdown Structure (RBS) is defined. My Direct Reports Resource Managers Intended for users who need to be able to approve timesheets.

301 DEFAULT CATEGORY DEFAULT GROUPS IN THE CATEGORY DESCRIPTION My Organization Portfolio Viewers Portfolio Managers Project Managers Resource Managers Administrators Used to grant access to all information in the organization. This category is intended for members of a Project Management Office (PMO), executives in an organization, and other key users who require the ability to view projects and resources across the entire organization. Task requirements The following are required to perform the procedures for this task: Access to Project Web App The Manage users and groups global permission in Project Web App in order to create, modify, or delete a category To manage categories in Project Web App, you can perform the following procedures: Create security categories in Project Server Modify categories in Project Server Delete a category (Project Server permission mode) See also Plan user access in Project Server Manage users, groups, and categories in Project Server Plan groups, categories, and RBS in Project Server Category permissions in Project Server 2013 Global permissions in Project Server 2013 Default categories in Project Server 2013

302 Create security categories in Project Server 12/14/ min to read Edit Online Summary: Add custom security categories by using the Manage Categories page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Web App, you can add custom security categories as necessary to create a security model that meets the specific needs of users and groups in your organization. Note Categories are only available in Project Server permission mode. If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Avoid creating unnecessary categories. Having lots of groups and categories in an organization can lead to greater administrative complexity. Additionally, having many groups and categories can stress the authorization system, which can affect performance. If there are many users at the highest level of the Resource Breakdown Structure (RBS), consider adding them to a custom category that enables them to view all projects (avoiding dynamic rules). Top-level RBS users probably have access to all projects, so assigning them to this category avoids unnecessary work by the authorization system. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage categories in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. To create a new category, perform the following procedure. To create a category 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Categories. 3. On the Manage Categories page, click New Category.

303 4. Complete the Add or Edit Category page. See the following sections for information about each setting. 5. Click Save. Name and Description Use the Name and Description section to specify a name and description for the category. The following table describes the name and description options for a category. ATTRIBUTE Category Name Description DESCRIPTION The name of the category. This name must different be than that of other categories. Description of the category. Projects Use the Projects section to specify the projects that users associated with this category can view. Users access to projects in this category are governed by the defined group and category permissions. You can also use one of the dynamic security options to have projects made available to users based on their relationship to the project or their RBS value. ATTRIBUTE Include all current and future projects Only include the selected projects Available projects Selected projects The User is the Project Owner or the User is the Status Manager on assignments within that Project The User is on that project's Project Team The Project Owner is a descendant of the User via RBS DESCRIPTION When this option is selected, users in this category can see all projects in this instance of Project Web App. When this option is selected, users in this category can view the projects in the Selected Projects list and any projects from the Available Projects list that the user has permissions to see with the dynamic permissions options. The dynamic permissions features only work when this option is selected. Projects that are not explicitly part of this category. Users may still be able to view these projects if any of the dynamic permissions options are configured to enable it. Projects that users in this category can view. Gives users permissions on any project they own. Also gives Status Managers permissions on projects that contain assignments that they manage. Gives users permissions on any project where they are on the project team. Users do not need to have assignments on the project. Gives users permissions on any project that is managed by resources subordinate to them in the RBS hierarchy.

304 ATTRIBUTE A resource on the project's Project Team is a descendant of the User via RBS The Project Owner has the same RBS value as the User DESCRIPTION Allows a user to view any project where a resource subordinate to the user in the RBS is a member of the project team. Avoid using this rule for users who have many resources under them in the RBS. If the resources under them are on many projects involving many categories, this stress on the authorization system can affect performance (for example, delay the loading of the Project Center page). Allows a user to view projects managed by persons that have the same RBS value that the user has. Resources Use the Resources section to specify which resources the users associated with this category can view. Users access to resources in this category are governed by the defined group and category permissions. You can also use one of the dynamic security options to have resources made available to users based on their relationship to the resource or their RBS value. ATTRIBUTE Include all current and future resources Only include the selected resources Available Resources Selected Resources The User is the resource They are members of a Project Team on a project owned by the User They are descendants of the User via RBS They are direct descendants of the User via RBS They have the same RBS value as the User DESCRIPTION When this option is selected, users in this category can see all resources in this instance of Project Web App. When this option is selected, users in this category can view the resources in the Selected Resources list and any resources from the Available Resources list that the user has permissions to see with the dynamic permissions options. Resources that are not explicitly part of this category. Users may still be able to view these resources if any of the dynamic permissions options are configured to enable it. Resources that users in this category can view. Gives users permissions to view information about themselves (such as assignments). Gives users permissions to view information for all resources in projects they own. Gives users permissions to view information for all resources under them in the RBS. Gives users permissions to view information about resources that are directly under them in the RBS. Gives user permissions to view information about resources that have the same RBS value. Views Use the Views section to specify views that users associated with this category can see.

305 To add a view to the category, select the Add check box for that view. To remove a view, clear the Add check box for that view. Permissions Use the Permissions section to specify which users and groups are associated with this category. To associate a user or group with this category, select the user or group in the Available Users and Groups list, and then click Add. To remove the association between a user or group and this category, select the user or group in the Users and Groups with Permissions list and then click Remove. For easiest administration, only associate groups with categories. ATTRIBUTE Available Users and Groups Users and Groups with Permissions DESCRIPTION Users and groups that are not associated with this category. Users and groups that are associated with this category. To select the category permissions for each user or group, select the user or group in the Users and Groups with Permissions list. This action enables the category permissions list for the selected group in this category. Each user or group can be assigned distinct permission in a category. For a complete list of category permissions, see Category permissions in Project Server See also Manage categories in Project Server Plan groups, categories, and RBS in Project Server Global permissions in Project Server 2013 Modify categories in Project Server Delete a category (Project Server permission mode)

306 Modify categories in Project Server 12/13/ min to read Edit Online Summary: Edit security categories by using the Manage Categories page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Web App, you can modify an existing category from the Manage Categories page on the Project Web App Server Settings page. You might want to do this, for example, if an existing category has to be updated for new projects and resources. Note Categories are only available in Project Server permission mode. If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage categories in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Modify a category Perform the following procedure to modify an existing category in Project Web App. To modify a category 1. On the PWA home page, on the Settings menu, click Server Settings. 2. On the Server Settings page, in the Security section, click Manage Categories. 3. On the Manage Categories page, in the Category Name list, click the name of the category that you want to edit. 4. On the Add or Edit Category page, make your changes to the category information. For information about the options on the page, see Create security categories in Project Server. 5. Click Save.

307 See also Plan groups, categories, and RBS in Project Server Global permissions in Project Server 2013 Create security categories in Project Server Delete a category (Project Server permission mode) Manage categories in Project Server

308 Delete a category (Project Server permission mode) 12/13/ min to read Edit Online Summary: Delete custom security categories by using the Manage Categories page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Web App, you can delete any existing custom category from the Manage Categories page in Project Web App. Note Default Project Server categories cannot be deleted. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage categories in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Delete a category Perform the following procedure to delete an existing category in Project Web App. To delete a category 1. On the Project Web App home page, on the Settings menu, click Server Settings. 2. On the Server Settings page, in the Security section, click Manage Categories. 3. On the Manage Categories page, in the Category Name list, find the category that you want to delete. Select the check box next to the category that you want to delete. Note that you can select multiple categories. 4. Click Delete Categories. A warning message appears, noting that the category will be permanently removed. Caution

309 Verify that the category you are deleting is the one you intend to delete. If you accidentally delete the wrong category, it is permanently deleted and will need to be recreated. 5. Click OK. See also Manage categories in Project Server Plan groups, categories, and RBS in Project Server Global permissions in Project Server 2013 Create security categories in Project Server Modify categories in Project Server

310 Manage security templates in Project Server 12/13/ min to read Edit Online Summary: Administrators can use security templates in Project Web App to standardize the granting of user permissions by role. Applies to: Project Server 2016, Project Server 2013 Security templates provide a means for you to quickly apply or reset predefined permission profiles to new or existing users, groups, and categories. By applying security templates, you can easily standardize the permissions that you assign according to user's role in the organization. A number of predefined security templates are available in each Project Web App instance. These align with the predefined groups. You can customize these security templates or create new security templates according to your needs. Creating custom templates requires planning. You must first identify the common Project Server usage patterns in your organization that are not reflected in the default Project Server security templates. This helps you identify your requirements for custom security templates. Then, determine the permissions that the users who share the common Project Server usage patterns require. This defines the security template. Next, determine the set of projects, resources, views, and so on, that the users and groups require access to. This defines the security category. Create the custom security template and apply it to the group of users who share the common usage pattern. The permissions that you define in the custom security template will enable users to access the Project Server security objects that they require. Security templates are available in Project Server permission mode. There are eight default security templates available in Project Web App: Administrators Portfolio Viewers Portfolio Managers Project Managers Proposal Reviewers Resource Managers Team Leads Team Members Each security template is given a set of default category and global permissions, based on the functions that each group typically does in an organization. As mentioned previously, when you create new security templates, you are allowed to copy the permissions for a default security template and then customize it to suit your needs. Note For information about the permissions assigned to default security templates in Project Server 2013, see Default group permissions in Project Server Task requirements The following are required to perform the procedures for this task:

311 Access to Project Web App The Manage users and groups global permission in Project Web App to create, change, or delete a security template To manage security templates in Project Web App, you can perform the following procedures: Create security templates in Project Server Modify security templates in Project Server Delete a security template (Project Server permission mode) See also Manage users, groups, and categories in Project Server Plan groups, categories, and RBS in Project Server Manage security group synchronization with Active Directory in Project Server Category permissions in Project Server 2013 Global permissions in Project Server 2013 Default group permissions in Project Server 2013

312 Create security templates in Project Server 12/14/ min to read Edit Online Summary: Create Project Web App security templates by using the Manage Templates page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, you can group commonly used permissions into a security template and then use it to assign permissions to users, groups, and categories. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage security templates in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Create a template Perform the following procedure to create a template in Project Web App. To create a template 1. On the PWA home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Security Templates. 3. On the Manage Templates page, click New Template. 4. On the Add or Edit Template page, in the Name section, do the following: 5. In the Template Name box, type a name for the template. 6. In the Description box, type a short description of the template. 7. Optionally, you can base the new template on an existing template, and then make any required changes. To do this, select an existing template from the Copy Template list. The new template will be populated with the security permissions from the template you selected. 8. In the Category Permissions section, select the permissions in the Allow or Deny column that you want to apply towards projects and resources whenever this template is used to set permissions.

313 For more information about specific category permissions in Project Server 2013, see Category permissions in Project Server In the Global Permissions section, select the permissions in the Allow or Deny columns that you want to apply across this instance of Project Web App whenever this template is used to set permissions. For more information about specific global permissions in Project Server 2013, see Global permissions in Project Server Click Save. See also Manage security templates in Project Server Modify security templates in Project Server Delete a security template (Project Server permission mode) Manage security group synchronization with Active Directory in Project Server Plan groups, categories, and RBS in Project Server

314 Modify security templates in Project Server 12/14/ min to read Edit Online Summary: Edit Project Web App security templates by using the Manage Templates page in Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 In Project Server permission mode, you can modify the permissions for any existing template in the Manage Templates page in Project Web App Settings. Important As a best practice, do not make any changes to the default Project Web App templates. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage security templates in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Modify a template Perform the following procedure to modify an existing template in Project Web App. To modify a template 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Security Templates. 3. On the Manage Templates page, in the Template Name list, click the template that you want to edit. 4. On the Add or Edit Template page, make your changes to the template. 5. Click Save. See also

315 Manage security templates in Project Server Create security templates in Project Server Modify security templates in Project Server Manage security group synchronization with Active Directory in Project Server Plan groups, categories, and RBS in Project Server

316 Delete a security template (Project Server permission mode) 12/14/ min to read Edit Online Summary: Learn how to delete Project Web App security templates by using the Manage Templates page in Project Web App Settings. Applies to: Project Server 2013 In Project Server security mode, you can delete any existing security templates from the Manage Templates page in Project Web App Settings. Important As a best practice, do not delete any of the default Project Web App templates. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage security templates in Project Server. You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Delete a template Perform the following procedure to delete an existing template in Project Web App. To delete a template 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Manage Security Templates. 3. On the Manage Templates page, in the Template Name list, select the check box next to the templates that you want to delete. 4. Click Delete Template. A warning message appears, noting that the template will be permanently removed.

317 5. Click OK. See also Manage security templates in Project Server Create security templates in Project Server Modify security templates in Project Server Manage security group synchronization with Active Directory in Project Server Plan groups, categories, and RBS in Project Server

318 Manage Project Web App permissions (Project Server permission mode) 12/18/ min to read Edit Online Summary: Project Web App global and category permissions can be disabled, but this action should be examined carefully before it is done. Applies to: Project Server 2013 In Project Server permission mode, you can use the Project Web App Permissions page to control which global and category permissions are enabled on a given Project Web App instance. An administrator can use the Project Web App Permissions page to deny access to all Project Web App users for a particular feature in Project Professional or a Project Web App instance. If a Project Web App permission is disabled on this page, the equivalent global or category permission is disabled for users throughout Project Web App. All permissions on this page are enabled by default. NOTE If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. For example, if you deny the Delete project permission, users throughout Project Web App cannot delete projects, regardless of whether they have the Delete project category permission. IMPORTANT Before disabling a Project Web App permission, thoroughly consider the effects on your organization of doing so. If you want to turn off a permission for only some Project Web App users, verify whether you can do it by creating a custom group and denying the permissions you want to restrict. Task requirements The following are required to perform the procedures for this task: Access to Project Web App The Manage users and groups global permission in Project Web App to manage Project Web App organizational permissions To manage Project Web App organizational permissions in Project Web App, you can perform the following procedure: Disable permissions in Project Web App (Project Server permission mode) (Project Server 2013) See also Plan groups, categories, and RBS in Project Server Manage users, groups, and categories in Project Server 2013 Category permissions in Project Server 2013

319 Global permissions in Project Server 2013 Permissions in Project Web App

320 Disable permissions in Project Web App (Project Server permission mode) (Project Server 2013) 12/13/ min to read Edit Online Summary: Project Web App global and category permissions can be disabled, but this action should be examined carefully before it is done. Applies to: Project Server 2013 In Project Server permission mode, you can disable individual permissions in Project Web App. Important In Project Web App, thoroughly consider the effects on your organization of disabling permissions before making such a change. If the removal of the permission does not need to be applied to all users, then verify whether another approach could be used. For example, could you create a custom group and deny the permission you want to restrict instead of disabling the permission throughout the organization? For information about how permissions work, see Plan groups, categories, and RBS in Project Server. Note If you are using SharePoint permission mode, see Plan SharePoint groups in Project Server for information about managing users in Project Web App. Before you begin Note Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For more information, see the following resources:> Plan browser support> Accessibility for SharePoint Products> Accessibility features in SharePoint 2013 Products> Keyboard shortcuts> Touch Before you begin this operation, review the following information about prerequisites: Read Manage Project Web App permissions (Project Server permission mode). You must have access to Project Web App. Important The Manage users and groups global permission in Project Web App is required to complete this procedure. Disable a Project Web App organizational permission Perform the following procedure to disable a Project Web App permission. To disable a Project Web App permission

321 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Security section, click Project Web App Permissions. 3. On the Project Web App Permissions page, in the Available Project Web App Permissions list, clear the Enable check box next to the permission that you no longer want to make available to Project Web App users. (All Project Web App permissions are enabled by default.) 4. Click Save. Note Enabling a previously disabled permission is simply done by selecting the Enable check box next to the permission that has been disabled. See also Manage Project Web App permissions (Project Server permission mode) Plan groups, categories, and RBS in Project Server

322 Manage delegates in Project Server 12/13/ min to read Edit Online Summary: Learn about how to manage delegates in Project Server. Applies to: Project Server 2013 Project Server enables user delegation throughout all of Project Web App. This means that one user can act as another user in every part of Project Web App, regardless of the permission level difference of one user compared to the other. Articles in this section include the following: Turn delegation on or off in Project Server Set up which users and groups can act as delegates in Project Server Set up which users and groups can have delegates in Project Server Create delegations in Project Server See also Delete user delegates in Project Server 2013 Act as a delegate (Project Server 2013)

323 Turn delegation on or off in Project Server 12/13/ min to read Edit Online Summary: The user delegation feature in Project Web App can be enabled or disabled globally, for all users and groups. Applies to: Project Server 2013 When user delegation is turned on, you can set permissions to control the specific behavior of the feature in Project Web App. To turn delegation on or off 1. On the PWA home page, click Server Settings. 2. On the Server Settings page, in the Security section, click Project Web App Permissions. 3. In the Resource section, select the check box for the Manage Resource Delegates permission to turn on the user delegation feature within Project Web App. 4. Choose any additional delegation permissions that meet your organization's needs: Manage My Resource Delegations Select this check box to enable users to set up delegations for other users. Manage My Delegations Select this check box to enable users to create delegations for themselves. Can be Delegate Select this check box to enable a user to become a delegate for another user, after a delegation has been created. 5. Click Save to save the permissions on the server. See also Create delegations in Project Server

324 Set up which users and groups can act as delegates in Project Server 12/13/ min to read Edit Online Summary: How to enable users or groups to act as delegates for other people in Project Server. Applies to: Project Server 2013 In Project Web App, there are user- or group-level permissions that enable you to determine which users or groups can act as delegates for other people. By default, the only group that has these permissions turned on is the administrators group. Therefore, if you want users in your organization to be able to act as delegates, you have to set the appropriate permissions. To set permissions for a specific user 1. On the PWA home page, click Server Settings. 2. In the Security section, click Manage Users. 3. Click the name of the user for which you are setting permissions. 4. On the Edit User page, expand the Global Permissions section. 5. In the Global Permissions section, under Resource, choose the appropriate permissions for this user. Can be Delegate Select the Allow check box for this permission to enable this user to become a delegate for another user. Manage My Delegations Select the Allow check box for this permission to enable this user to create his or her own delegations. Manage My Resource Delegations Select the Allow check box for this permission to enable this user to set up delegations for other users. 6. Click Save to save the permissions on the server. To set permissions for a group 1. On the PWA home page, click Server Settings. 2. In the Security section, click Manage Groups. 3. Click the name of the group for which you are setting permissions. 4. On the Add or Edit Group page, expand the Global Permissions section. 5. In the Global Permissions section, under Resource, choose the appropriate permissions for this group. Can be Delegate Select the Allow check box for this permission to enable members of this group to become delegates for other users. Manage My Delegations Select the Allow check box for this permission to enable members of this group to create their own delegations. Manage My Resource Delegations Select the Allow check box for this permission to enable members of this group to set up delegations for other users. 6. Click Save to save the permissions on the server.

325 See also Set up which users and groups can have delegates in Project Server

326 Set up which users and groups can have delegates in Project Server 12/13/ min to read Edit Online Summary: How to set up who can have delegates assigned to them in Project Server. Applies to: Project Server 2013 Categories are used in Project Web App to determine which users or groups can have delegates do work on their behalf. In order for a delegation to work correctly, the user requesting the delegation must have the correct category permissions, and the user who will act as the delegate must have the correct individual user or group permissions. To set up who can have delegates assigned to them 1. On the PWA home page, click Server Settings. 2. In the Security section, click Manage Categories. 3. Click the name of the category that contains the user or group for which you want to enable user delegation. 4. In the Users and Groups section, click the name of group or a specific user in the Users and Groups with Permissions box. 5. In the permissions box that appears, scroll down to the Resource section, and select the check box for the Manage Resource Delegates permission to turn on the user delegation feature for that user or group. 6. Click Save to save the permissions on the server. See also Set up which users and groups can act as delegates in Project Server

327 Create delegations in Project Server 12/13/ min to read Edit Online Summary: How to enable one user to work on behalf of another in Project Server. Applies to: Project Server 2013 Creating a new delegation in Project Web App enables one user to work on behalf of another user, such as submitting a second user's timesheet. To create a delegation 1. On the PWA home page, click Server Settings. 2. In the Security section, click Manage Delegates. 3. On the interface ribbon, click New. 4. In the Set Delegation Period section, select the date range for the period during which the delegate will be able to manage work. 5. In the Set Delegation section, select the delegate that you want to manage work during the specified period. 6. In the Working on Behalf of section, select the user who requires a substitute. 7. Click Save to save the permissions on the server. See also Turn delegation on or off in Project Server

328 Manage security group synchronization with Active Directory in Project Server 12/13/ min to read Edit Online Summary: You can configure Project Server security groups in Project Web App to synchronize with security or distribution groups in Active Directory. Applies to: Project Server 2016, Project Server 2013 Note To configure Active Directory synchronization to Project Web App security groups, your Project Server instance must be in Project Server Permission Mode. The settings are not available in SharePoint Permission Mode. For more information about Project Server Permission Mode, see Plan user access in Project Server. Project Server security group synchronization controls Project Server security group membership by automatically adding and removing users from specified Project Server security groups based on group membership in the Active Directory directory service. Each Project Server security group can be mapped to a single Active Directory group. Additionally, an Active Directory group can contain nested groups whose members are also synchronized. The following actions can occur during a Project Server security group synchronization process: A new Project Server user account can be created based on an Active Directory account. An existing Project Server user can be removed from a Project Server security group. An existing Project Server user can be added to a Project Server security group. An existing Project Server user account's metadata (name, address, and so on) can be updated if it has changed in Active Directory. Before you perform this procedure, confirm the following: The account with which you are accessing Project Server through Project Web App (PWA) has both the Manage Active Directory Settings and the Manage users and groups global permissions enabled. The Service Application service account for the Project Server instance has Read access to all Active Directory groups and user accounts involved in the synchronization. You can verify this account on the Service Application page on the SharePoint Central Administration website. Security group synchronization scenarios The following are possible scenarios and corresponding actions that occur when security group synchronization takes place: SCENARIO The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user does not exist in Project Server. ACTION A new corresponding user account is created in Project Server and is granted membership to the current Project Server security group.

329 SCENARIO ACTION The user is not a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server and is a member of the current Project Server security group. The existing Project Server user is removed as a member of the current Project Server security group. The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server, but is not a member of the current Project Server security group. The existing Project Server user is given membership to the current Project Server security group. The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server and is a member of the current Project Server security group. User information has been updated in Active Directory. The corresponding Project Server user information is updated (if applicable). The user exists in Active Directory and is a member of the Active Directory group mapped to the current Project Server security group. The user also exists in Project Server, but as an inactive account. If the Automatically reactivate currently inactive users if found in Active Directory during synchronization option is selected in Project Server, the account is reactivated and is added to the current Project Server security group. If the option is not selected, the account remains inactive in Project Server. Configure security group synchronization with Active Directory groups Project Web App security group synchronization with Active Directory groups is done through the Manage Groups page of your Project Web App Server Settings. To configure security group synchronization 1. On the Project Web App Server Settings page, in the Security section, click Manage Groups. 2. On the Manage Groups page, in the Group Name column, click the name of the security group that you want to synchronize. 3. On the Add or Edit page for the group that you selected, in the Active Directory Group section, type the name or SAM account of the Active Directory group to which you want to synchronize with this PWA group. As you type the group name, Active Directory groups that contain the text string will appear in the results. Select the Active Directory group that you want to synchronize from the results. To select a group from a remote forest, type the fully qualified domain name of the group (for example, group@corp.contoso.com). Note You can synchronize to a security or distribution group of any scope (Local, Global, or Universal). 4. Click Save to save the settings. 5. On the Manage Groups page, click Active Directory Group Sync Options. 6. On the Sync Project Web App security groups with Active Directory dialog page, you can enable inactive user accounts to be reactivated if they are found in the Active Directory group during synchronization. To do so, select Automatically reactivate currently inactive users if found in Active Directory during sync. For example, if you enabled this option, it would ensure that if an employee were rehired, the employee's user account would be reactivated.

330 7. Click Save to save the settings. Click Save and Synchronize Now if you want to synchronize your Project Server security groups immediately. The Status section describes the last time Project Web App groups were synchronized with Active Directory. Note Clicking the Save and Synchronize Now button will synchronize all security groups to configured Active Directory groups. Do not select individual security groups at the manage groups page before clicking Active Directory Group Sync Options, as this does not affect which groups are synchronized. You can view the Manage Groups page to see which PWA security groups are synchronized to Active Directory groups and the last time synchronization occurred for each security group. The Active Directory Group column shows which Active Directory groups are configured to synchronize with a PWA security group. The Last Sync column shows the last time synchronization occurred successfully for each group. Schedule Active Directory synchronization to PWA security groups You can schedule the frequency that Active Directory synchronization to PWA security groups occurs by using the Project Server: Synchronization of AD with security groups timer job configuration settings in Central Administration. This can be scheduled over a defined period of minutes, days, weeks, or months. The following procedure shows you how to access the Project Server: Synchronization of AD with security groups timer job configuration settings in Central Administration and describes the scheduling options that are available. To schedule Active Directory synchronization to PWA security groups 1. In Central Administration, click Monitoring. 2. On the Monitoring page, in the Timer Job section, click Review job definitions. 3. On the Job Definitions page, find and click Project Server: Synchronization of AD with security groups for. For example: Project Server: Synchronization of AD with security groups for 4. On the Edit Timer Job page for the job, in the Recurring Schedule section, you can configure when the synchronization will run on a recurring basis. In the This timer job is scheduled to run section, you can select one of the following options, based on your organization's requirements: Minutes: Allows you to specify a frequency in which the job will run Every x minutes. Hourly: Allows you to specify an interval in which the job will randomly run Starting every hour between x minutes past the hour and no later than y minutes past the hour. Daily: Allows you to specify an interval in which the job will randomly run Starting every day between and no later than. Weekly: Allows you to specify in which the job will randomly run Starting every week between and no later than. Monthly: Provides two options: Allows you to specify an interval in which the job will randomly run By date: starting every month between and no later than. Allows you to specify an exact time of the month in which the timer job will run By day:

331 starting every month <time of day, day of the week, and week of the month. For example, 12:00AM on the first Sunday. 5. Click OK to save your configuration changes. Note You can click Run Now at any time to run the timer job immediately. Notice that several options provide you a period of execution time to run the job instead of an exact time or frequency. Selecting an option that provides a period of execution time allows the timer service to select a random time within the parameters specified in order to run the job on each application server. Using an option with a period of execution time is appropriate for high-load jobs which run on multiple servers in the farm. Running this type of job on all servers of the servers simultaneously might place an unreasonable load on the farm. Various factors may help you determine the frequency in which you choose to run the Project Server: Synchronization of AD with security groups timer job. You may want to choose to run this timer job more frequently if, in your environment, users frequently move to different groups, or if your company frequently hires or releases employees. You may also want to choose to run the job more frequently if your Project Server users are working with sensitive data. See also Manage Active Directory Resource Pool synchronization in Project Server 2013 Manage security groups in Project Server Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server 2013

332 Enterprise custom fields and lookup tables in Project Web App 12/13/ min to read Edit Online Summary: Use enterprise custom fields and lookup tables in Project Web App to customize Project Server data. Applies to: Project Server 2016, Project Server 2013 In Project Web App, you can use Enterprise Custom Fields to help establish consistency across all the organization's projects. That way that you can ensure that fields and associated lookup tables are used in the same manner for all projects, tasks, resources, and assignments in a given instance of Project Web App. Enterprise Custom Fields can include custom formulas and can use lookup tables and graphical indicators. By using Enterprise Custom Fields effectively, you can help customize Project Web App to fit the unique needs of your organization. When you use Enterprise Custom Fields, all users in your organization have access to a standard set of fields, which enables operations to be applied in the same manner across whole sets of projects. For example: You can customize project management to reflect your organization's structure and processes. All users in your organization can have access to a standard set of fields, which enables the same operations to be completed across whole sets of projects. You can set Enterprise Custom Fields as required fields so that users are prompted to enter information in that field before they save. You can use Enterprise Custom Fields on a per-department basis. Because creating Enterprise Custom Fields can range from being easy to being very complex and labor-intensive, it is important to correctly design your Enterprise Custom Fields. To determine the scope of Enterprise Custom Fields that your organization requires, consider the following questions: What words or phrases are used by stakeholders in your organization, such as return on investment (ROI), Key Performance Indicator (KPI), and so on? You might want to quantify and codify these concepts by using Enterprise Custom Fields. Also consider the concepts behind the common words and phrases used by stakeholders in your organization. What are the user requirements in your organization? User requirements are frequently based on reporting requirements. How will you sort and select data? How will you use graphical indicators? Enterprise Custom Fields You can create Enterprise Custom Fields at the task, project, and resource level. It is important to determine which specific Enterprise Custom Fields your organization needs when you review your business requirements while planning your Project Server deployment. It is best to do this after you have performed a gap analysis by comparing the capabilities of Project Server against the business needs of your organization. For example, a group of executives in an organization wants to be able to view project data by department. In order to achieve this business requirement, they have to define a consistent method for identifying departments within the organization. In addition, if each department has a different accounting method or funding process, the executives might have to determine a method for defining this, also. You can use the Project Departments or Resource Departments custom fields together with the Department custom lookup table, or any enterprise custom field that has the Department property set to do this.

333 The most important use for Enterprise Custom Fields is to enable organizations to enforce consistency across all projects. For example, if two project managers use different fields to specify a resource's location, then users are unable to determine when the same resource is assigned to projects managed by each project manager. Note that using a lot of custom fields with formulas can have a performance impact on your system. Enterprise Custom lookup tables Consider using custom lookup tables for any Enterprise Custom Field for which standardization of data is the most important factor. For example, it might not be a good practice to let users enter an arbitrary value in a custom Status field. One project manager might enter Started, and another might enter In-Progress, both indicating that the project has begun and is underway. Without using lookup tables, it is difficult to standardize terminology in your organization. For example, you might create a custom text field that is associated with Resources. To do this, you click the Resource option, select Text from the list, and rename itmanager. If you do not specify a lookup table for this custom text field, a user could enter any text value in the Manager field. See also Add or edit enterprise custom fields in Project Server Add or edit enterprise custom lookup tables in Project Server

334 Add or edit enterprise custom fields in Project Server 12/13/ min to read Edit Online Summary: Use the New Custom Field page in Project Web App settings to specify the options for a custom field. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to create a new enterprise custom field or edit an existing one. To create or edit Enterprise Custom Fields 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Project Web App Server Settings page, click Enterprise Custom fields and Lookup Tables. 3. In the Enterprise Custom Fields section, click the field that you want to edit, or click New Field to create a new field. 4. Fill out the Custom Field page by specifying the custom field options that you want to use. See the descriptions for each field in the following sections. 5. Click Save. Name and Description Use the Name and Description areas to specify a name and description for the custom field. The following table describes the name and description fields. Note If you plan to use custom fields in your OLAP cubes, avoid using non-alphanumeric characters in the name. Name and Description attributes for custom fields in Project Web App ATTRIBUTE DESCRIPTION Name Description The name of the custom field. A description of the custom field. Entity and Type Use the Entity and Type areas to specify whether you want a Project, Resource, or Task custom field, and what data type the field should be. Note that Entity and Type cannot be edited after the custom field has been saved. The following table describes each available entity. Entity options for custom fields in Project Web App ATTRIBUTE DESCRIPTION Project Select to create Enterprise Custom Fields that are applied at the project level.

335 ATTRIBUTE Resource Task DESCRIPTION Select to create Enterprise Custom Fields that are applied at the resource level. Select to create Enterprise Custom Fields that are applied at the task level. The Type selection defines the data type of the custom field. The value that you choose here affects which options are available in the Custom Attributes, Calculation for Summary Rows, and Behavior sections. The following table describes the available custom field types. Type attributes for custom fields in Project Web App ATTRIBUTE Cost Date Duration Flag Number Text DESCRIPTION Use custom cost fields to define currency data. For example, you can use a custom cost field to define a project's Approved Budget. Use custom date fields to specify date-driven data. For example, you can create an Enterprise Custom Field called Project Approval Date and use it to record the date on which a project is approved. Use custom duration fields to define a duration. These are frequently defined as calculations that use custom formulas. For example, a custom duration field can enable your organization to define a way for a project manager to show and store the difference between a project's original schedule and the actual schedule. Use custom flag fields to define anything that can have only two choices for defining the data. For example, you might use a flag field to determine whether to display a field or to enable a macro that controls whether a particular set of data is available in the project. Use custom number fields to define any numeric set of data or to perform a custom calculation by using a custom formula. For example, you might use a task-level field to record the estimated lines of code in a software development project or to compare a project's actual cost to its proposed cost. Use custom text fields to define simple, non-hierarchical, alphanumeric data. For example, you can create a custom text field that is named Project Status that includes options such as Initiated, Approved, In-Progress, Suspended, Cancelled, and Closed. Custom attributes When you select a Project Text custom field, you have the option of specifying one or multiple lines of text for the custom field. The following table describes the custom text options. Custom text attributes for custom fields in Project Web App

336 ATTRIBUTE Single line of text Multiple lines of text DESCRIPTION Select if you want the custom field to be a single line of text. This option is available only for Project Text fields. Select if you want the custom field to be multiple lines of text. This option is available only for Project Text fields. The project field created by using this option is not visible in the project information tab in Project Professional. However, this field can be exposed by using a Web-based Project Detail Page. You can choose to have a custom lookup table supply the values for a custom field. This lets you control the values selected for the custom field. You can do the following: Choose whether to have a default value if no other value is selected Choose whether to allow multiple values to be selected from the lookup table Choose to restrict available values to those values in the table that have no subordinates The lookup table option is available when you have selected Text as the field type. The following table describes the lookup table options for custom fields. Lookup table attributes for custom fields in Project Web App ATTRIBUTE Lookup Table Choose a value to use as a default when adding new items Default value Only allow codes with no subordinate values Allow multiple values to be selected from lookup table DESCRIPTION The name of the Enterprise Custom Lookup Table that you want to associate with this custom field. Once you have associated a lookup table with a field and have saved it, you cannot remove the lookup table relationship. Therefore, make sure that you need the lookup table before you make this association. If you want to have a default value included in this custom field in cases where the user does not specify one, select this check box, and then select the default value. The default value to be used in this field when users do not specify a value. To set the value, click the browse button and select the desired value. Select this option if you want to allow only values in the lookup table that have no subordinate values (that is, values at the lowest level of each branch). Select this option if you want to allow users to select more than one value from the lookup table. Once this selection has been made and saved, it cannot be removed. This option is not compatible with OLAP cubes. Note If you plan to create a custom field that refers to a lookup table, create the lookup table before creating the custom field. You can use formulas to define your own parameters for how your Enterprise Custom Fields measure data or present information when they are used in a project. Formulas cannot be used with all types of Enterprise Custom

337 Fields. The formula option is available with all field types. Note Once a formula is associated with a custom field, it can be edited but it cannot be removed. To use a known formula, type the formula in the Edit formula box. To add a field to the formula, click Pick field, point to a field type, and then click the name of the field that you want to reference. To reference an existing Enterprise Custom Field, point to a field type, point again to a custom field type (such as Custom Date or Custom Finish), and then click the Enterprise Custom Field that you want. To use a function in the formula, click Pick function, click a function type, and then click the function that you want. Each function includes placeholder arguments that you can replace with the fields and values that you want to use. To build a formula by using a standard set of operators, click Pick operator and choose the operator that you need. The formula can operate by using referenced fields, functions, or literal data. The following table describes the formula options. Formula attributes for custom fields in Project Web App ATTRIBUTE Enter formula Insert field Insert function Insert operator DESCRIPTION The formula you want to use. Inserts a field (cost, date, duration, flag, number, or text) into the formula. Inserts a function (conversion, date/time, general, math, Microsoft Project, or text) into the formula. Inserts an operator (mathematical or Boolean) into the formula. Department You can select a department to be associated with a custom field. Selecting a department allows you to limit a user's ability to see the custom field if that person is not a member of that department. If you do not specify a department, then all users are able to see the custom field. The values available for Department are specified in the Department custom lookup table. Calculation for summary rows For entity types of Resource and Task, you can select options for the calculation of summary rows. Note that summary row calculation is not available with a field type of Text. The following table describes the options for summary task calculation. Summary task calculation options for custom fields in Project Web App

338 ATTRIBUTE None Rollup Use formula DESCRIPTION Choose None if you do not want the custom field to be applied to summary and group summary rows. Choose Rollup to roll up the individual rows for the summary row. Choose Use formula to use a specific formula to calculate the summary row. You must specify the formula to use under Custom Attributes. Calculation for assignment rows For resource types of Resource and Task, you choose to use a roll down calculation for assignment rows. The following table describes the options for calculating assignment rows. Assignment row calculation options in custom fields in Project Web App ATTRIBUTE None Roll down, unless manually specified DESCRIPTION Choose None if you do not want to roll down assignment rows. Choose Roll down if you want data that is entered at the task or resource level to be rolled down and copied to each assignment with the same value. Values to display You can choose to display raw data or to have the data represented graphically. If you select Graphical indicators, you can select different criteria for Non-summary rows, Summary rows, and, if you are using an entity type of Project, Project summary. When you select an option, further configurable parameters specific to that option are displayed. The following table describes the options for graphical indicators. Graphical indicator options in custom fields in Project Web App ATTRIBUTE Non-summary rows Summary rows Project summary DESCRIPTION Choose Non-summary rows to specify criteria for graphical representation of data rows that are not summary rows. Choose Summary rows to specify criteria for graphical representation of summary rows. Choose Project summary to specify criteria for graphical representation of the project summary. When you configure graphical indicators, you can specify the exact value and comparison parameters that determine when a particular graphic is used. The available comparison (test) parameters are as follows: Equals

339 Does not equal Is greater than Is greater than or equal to Is less than Is less than or equal to Is within Is not within Contains Does not contain Contains exactly Is any value These are used to compare the data value with a threshold value that you specify to determine which graphic to display. For example, you can configure values greater than or equal to 50 to display a green indicator and values less than 50 to display a red indicator. You can specify as many images for different values as required. Add a new row to the table for each test/value comparison. Rows in the table are evaluated from top to bottom and the image associated with the first row where the test/value combination is true is displayed. The following table describes the graphical indicator options for non-summary rows. Graphical indicator attributes for non-summary rows in custom fields for Project Web App ATTRIBUTE Test Values Images Move Show data values in ToolTips DESCRIPTION Choose the operator (equals, less than, and so on) to apply to the field value to determine the image to use. Type the field value or a field reference (for example, [cost]) that, combined with the operator in the test column, determines when to use the image in the Image column. Choose the image to display when the test/value combination is true. Use the move buttons to move a row up or down in the table. Select this attribute to show the field value in the tool tip associated with the image. When you use graphical indicators for summary rows, you can choose to inherit the graphical indicator settings that you have defined for non-summary rows. If you select the Inherit criteria from non-summary rows check box when you configure graphical indicators for summary rows, the graphical indicator parameters that you configured for the non-summary rows are used. If you select the Inherit criteria from summary rows check box when you configure graphical indicators for project summary, the graphical indicator parameters that you configured for the summary rows will be used.

340 Behavior You can configure a custom field to be controlled by workflow or to require a value. If you choose to have the custom field controlled by a workflow, the required field option is not available because that behavior is controlled by workflow. The following table describes the options for configuring custom field behavior. Custom field behavior options in Project Web App ATTRIBUTE Behavior controlled by workflow Allow editing on Project Detail pages for SharePoint Task List Projects Require that this field has information DESCRIPTION Select this check box if you want the custom field behavior to be controlled by workflow. Select this option if you want this custom field to be available to users editing SharePoint task list projects. Choose whether you want this to be a required field (that is, the field cannot be left blank). This option is not available if the Behavior controlled by workflow option is selected. See also Add or edit enterprise custom lookup tables in Project Server

341 Add or edit enterprise custom lookup tables in Project Server 12/13/ min to read Edit Online Summary: Use the New Custom Field page in Project Web App settings to specify the options for a custom lookup table. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to create or edit an enterprise custom lookup table. To create or edit Enterprise Custom Lookup Tables 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Project Web App Server Settings page, click Enterprise Custom fields and Lookup Tables. 3. In the Lookup Tables for Custom Fields section, click New Lookup Table to create a new lookup table, or click the lookup table that you want to edit. 4. For a new table, type a name for the lookup table in the Name box. 5. Fill out the Custom Lookup Table page by specifying the options that you want to use. See the descriptions for each field in the following sections. 6. Click Save. Type For a new lookup table, you must specify a data type for the table. It is not possible to mix field types in a table. The following table describes the options for data types in a custom lookup table. Data types for custom lookup tables in Project Web App ATTRIBUTE DESCRIPTION Cost Date Duration Number Text Each field in the table is a cost value. Each field in the table is a date value. Each value in the table is treated as a duration. Each value in the table is a number. Each value in the table is text. Choosing Text also allows a hierarchy of values to be specified if you want. Code mask The code mask option only appears when a field type of Text has been selected. The code mask lets you specify what types of text characters appear in the lookup table, the length of the string, and what characters to use to separate levels in a hierarchy. If you are creating a hierarchical lookup table, you

342 must specify a code mask for each level of the hierarchy. The following table describes the options available for configuring code masks. Code mask settings for a custom lookup table in Project Web App ATTRIBUTE Code preview Sequence Length Separator DESCRIPTION Displays a preview of the code mask for the table. Specify the type of text characters to allow. Choose Numbers, Uppercase characters, Lowercase characters, or Characters. Specify the maximum length of the string. Choose a number from 1 to 255 or Any. Specify from one to three characters to use as a separator between levels of the table hierarchy. Lookup Table Use the Lookup Table section of the New Lookup table page to specify the values in the lookup table. Type each value that you want in the lookup table in the Value column. Create as many rows as needed to accommodate the values that you want to include. Optionally, include a description for the value in the Description column. The following table describes the options for creating lookup table values. Lookup table values in Project Web App ATTRIBUTE Level Value Description Move Display order for lookup table DESCRIPTION Denotes the level in the hierarchy. This is a read-only field. Select the row and use the Indent and Outdent buttons to change levels. Specify the value of the field. Describes what the field represents. (Optional) Use the Move buttons to change the position of rows in the table. Select a row and then click the Up or Down Move button to move a row. Specifies how to sort the lookup table. If you select By row number, the table remains sorted as you specify it. If you choose to sort ascending or descending, the table is sorted based on the values in the Value column. See also Add or edit enterprise custom fields in Project Server

343 Database administration in Project Server 12/13/ min to read Edit Online Summary: Manage your enterprise objects in the Database Administration section of Project Server Settings. Applies to: Project Server 2016, Project Server 2013 CONTENT Delete enterprise objects in Project Server Force check-in enterprise objects in Project Server DESCRIPTION You can delete enterprise objects from Project Web App when they are no longer needed. You can force the check-in of enterprise projects, resources, custom fields, calendars, lookup tables, and resource plans in Project Web App. See also Use Project Server

344 Delete enterprise objects in Project Server 12/13/ min to read Edit Online Summary: You can delete enterprise objects from Project Web App when they are no longer needed. Applies to: Project Server 2016, Project Server 2013 You can delete the following types of objects from Project Web App: Projects Resources and users Status report responses Timesheets User delegates See the articles in this section for procedures to delete each type of object: Delete projects in Project Server Delete resources and users in Project Server Delete status report responses in Project Server Delete timesheets in Project Server Delete user delegates in Project Server See also Force check-in enterprise objects in Project Server

345 Delete projects in Project Server 12/13/ min to read Edit Online Summary: When a project is no longer needed, you can delete it from Project Web App using the Delete Enterprise Objects option. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to delete a project from Project Web App. Important The project is permanently deleted from Project Web App and it cannot be retrieved. To delete a project 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Delete Enterprise Objects. 3. On the Delete Enterprise Objects page, select the Projects option. 4. Select one of the following options: Delete draft and published projects to display a list of both Draft and Published projects. Delete only published projects to display a list of Published projects. Delete archived projects to display a list of Archived projects. 5. To delete the associated SharePoint site, select the Delete the connected SharePoint sites check box. Note If you do not delete the associated SharePoint site and you save and publish a new project with the same name as the deleted project, the SharePoint site publishing process will fail. 6. Select the project that you want to delete. 7. Click Delete.

346 Delete resources and users in Project Server 12/13/ min to read Edit Online Summary: When a resource or user is no longer needed, you can delete it from Project Web App. Applies to: Project Server 2016, Project Server 2013 Important We recommend not deleting resources from Project Web App as this can affect the reporting of actuals. Instead, deactivate resources that are no longer needed. Use the following procedure to delete resources and users from Project Web App. Important The resources and users will be permanently deleted from Project Web App. To delete resources and users 1. On the Project Web App home page, on the Settings menu, click PWA Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Delete Enterprise Objects. 3. On the Delete Enterprise Objects page, select the Resources and Users option. 4. Select the user or resource that you want to delete. 5. Click Delete. 6. On the confirmation dialog box, click OK.

347 Delete status report responses in Project Server 12/13/ min to read Edit Online Summary: When a status report response is no longer needed, you can delete it from Project Web App. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to delete status report responses from Project Web App. Important This process deletes the status report response completely from Project Web App and it cannot be retrieved. To delete status report responses 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Delete Enterprise Objects. 3. On the Delete Enterprise Objects page, select the Status Report Responses option. 4. Specify a period end date parameter (number of days, weeks, months, or years ago before which you want to delete all status report responses). 5. Click Delete.

348 Delete timesheets in Project Server 12/13/ min to read Edit Online Summary: When a timesheet is no longer needed, you can delete it from Project Web App. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to delete timesheets from Project Web App. Important That this process deletes the timesheet completely from Project Web App and it cannot be retrieved. To delete timesheets 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Delete Enterprise Objects. 3. On the Delete Enterprise Objects page, select the Timesheets option. 4. Select the range of timesheet end dates that you want to delete. 5. Click Delete. See also TimeSheet.QueueDeleteTimesheet method

349 Delete user delegates in Project Server 12/13/ min to read Edit Online Summary: When a user delegate is no longer needed, you can delete it from Project Web App. Applies to: Project Server 2016, Project Server 2013 Use the following procedure to delete user delegates from Project Web App. Important This process deletes the user delegate completely from Project Web App and it cannot be retrieved. To delete a user delegate 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Delete Enterprise Objects. 3. On the Delete Enterprise Objects page, select the User Delegates option. 4. Specify a period end date parameter (number of days, weeks, months, or years before which you want to delete all user delegates). 5. Click Delete.

350 Force check-in enterprise objects in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in of enterprise projects, resources, custom fields, calendars, lookup tables, and resource plans in Project Web App. Applies to: Project Server 2016, Project Server 2013 If an enterprise object is checked out and the user who checked it out is unavailable or unable to check it back in, you can force a check-in. Important If you force check-in an enterprise object that a user is modifying, the modifications may be lost. You can force check-in the following types of enterprise objects: Enterprise projects Enterprise resources Enterprise custom fields Enterprise calendars Lookup tables for enterprise custom fields Resource plans See the articles in this section for procedures to check-in each type of object: Check-in enterprise projects in Project Server Check-in enterprise resources in Project Server Check-in enterprise custom fields in Project Server Check-in enterprise calendars in Project Server Check-in lookup tables for enterprise custom fields in Project Server Check-in resource plans in Project Server See also Delete enterprise objects in Project Server

351 Check-in enterprise projects in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in an enterprise project by using Project Web App. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise project that is checked out. Note that forcing a check-in of a project that is being modified by a user may result in the loss of those changes. We highly recommend that users check in projects in the typical manner and that you use force check-in only when it is absolutely necessary. Use the following procedure to force check-in enterprise projects. To force check-in enterprise projects 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in Enterprise Objects. 3. From the Select the type of object you want to force check-in drop-down list, select Enterprise Projects. 4. Select the projects that you want to check in. 5. Click Check In.

352 Check-in enterprise resources in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in of an enterprise resource by using Project Web App. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise resource that is checked out. Note that forcing a check-in of a resource that is being modified by a user may result in the loss of those changes. Use the following procedure to check in enterprise resources. To check in enterprise resources 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in Enterprise Objects. 3. From the Select the type of object you want to force check-in drop-down list, select Enterprise Resources. 4. Select the resources that you want to check in. 5. Click Check In.

353 Check-in enterprise custom fields in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in of an enterprise custom field by using Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise custom field that is checked out. Note that forcing a check-in of a custom field that is being modified by a user may result in the loss of those changes. Use the following procedure to force check-in enterprise custom fields. To force check-in enterprise custom fields 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in Enterprise Objects. 3. From the Select the type of object you want to force check-in drop-down list, select Enterprise Custom Fields. 4. Select the custom fields that you want to check in. 5. Click Check In.

354 Check-in enterprise calendars in Project Server 12/13/ min to read Edit Online Summary: You can force check-in of an enterprise calendar by using Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise calendar that is checked out. Note that forcing a check-in of an enterprise calendar that is being modified by a user may result in the loss of those changes. Use the following procedure to force check-in enterprise calendars. To force check-in enterprise calendars 1. On the Server Settings page, click Force Check-in Enterprise Objects. 2. From the Select the type of object you want to force check-in drop-down list, select Enterprise Calendars. 3. Select the calendars that you want to check in. 4. Click Check In.

355 Check-in lookup tables for enterprise custom fields in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in of a lookup table for enterprise custom fields by using Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise lookup table that is checked out. Note that forcing a check-in of a lookup table that is being modified by a user may result in the loss of those changes. Use the following procedure to force check-in lookup tables. To force check-in lookup tables for enterprise custom fields 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in Enterprise Objects. 3. From the Select the type of object you want to force check-in drop-down list, select Lookup Tables for Enterprise Custom Fields. 4. Select the lookup tables that you want to check in. 5. Click Check In.

356 Check-in resource plans in Project Server 12/13/ min to read Edit Online Summary: You can force the check-in an enterprise resource plan by using Project Web App Settings. Applies to: Project Server 2016, Project Server 2013 You can force the check-in of an enterprise resource plan that is checked out. Note that forcing a check-in of a resource plan that is being modified by a user may result in the loss of those changes. Use the following procedure to force check-in resource plans. To force check-in resource plans 1. On the Project Web App home page, on the Settings menu, click Project Web App Settings. 2. On the Server Settings page, in the Queue and Database Administration section, click Force Check-in Enterprise Objects. 3. From the Select the type of object you want to force check-in drop-down list, select Resource Plans. 4. Select the resource plans that you want to check in. 5. Click Check In.

357 Operational Policies in Project Server /13/ min to read Edit Online Summary: Manage your enterprise settings in the Operational Policies section of Project Server Settings. The Operational Policies administrative settings are part of the Project Server Server Settings. Articles about operational policies in Project Server Settings The following articles about operational policies settings in Project Server are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT DESCRIPTION Alerts and reminders in Project Server 2013 Manage Active Directory Resource Pool synchronization in Project Server 2013 Manage connected SharePoint sites in Project Server 2013 Use the Alerts and Reminders page in SharePoint Central Administration to configure notification settings for Project Server The Active Directory Resource Pool Synchronization settings in Project Server provide a method to quickly add Active Directory users as enterprise resources. You can use the Connected SharePoint Sites Project Web App settings page to manage project sites.

358 Alerts and Reminders (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Alerts and Reminders page in SharePoint Central Administration to configure notification settings for Project Server Applies to: Project Server 2013 The Alerts and Reminders Project Server settings page in SharePoint Central Administration is used to configure notification settings in your Project Server 2013 environment. There settings on the Alerts and Reminders page are for the two types of notification s that Project Server sends: Alerts: This is an that is sent based on a triggering event. For example, an alert can be generated for a resource when a project manager assigns a new task to it. Reminders: This is an that is sent daily noting events that are upcoming or overdue. For example, a reminder for a team member can include a task that it owns that is scheduled to start tomorrow. Configuration of the Alerts and Reminders page is required for Project Server 2013 to use the automated notification system. On the Alerts and Reminders page, you can: Configure a connection to an SMTP mail server and associated port number. Specify the default sender address and message information that is automatically included with each notification or reminder that is sent by Project Server. In order to access and use the Alerts and Reminders Project Server settings page in SharePoint Central Administration, you must be a farm administrator. Notification settings To configure the notification settings 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Administrative Backup settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Administrative Backup settings, and click Manage. 5. On the Project Web App Server Settings page, in the Operational Policies section, click Alerts and Reminders. 6. On the Alerts and Reminders page: Select Turn on notification with the following settings to maintain all of your notification settings. You must select this option for your settings on this page to apply. Deselecting this option allows you to keep your configuration settings on the page, but have them be non-applicable. For the SMTP mail server box, enter the server name. Verify the port used in the Port box (default value of 25). Change the Port value if your SMTP server uses a port other than the default port for SMTP (Port 25).

359 In the From address box, enter the default address from which the will be sent. This address is the reply-to address for all notification and reminder s. In the Company domain box, type the domain name of your company (for example, Contoso.com). In the footer box, type the default message that you want appended to all notification s. For example: This message may contain confidential information and is intended for the recipients named above. 7. Click Save.

360 Active Directory Resource Pool Synchronization for Project Server /14/ min to read Edit Online Summary: This article set describes how to manage and plan for synchronization between Active Directory groups with the Enterprise Resource Pool in Project Server Applies to: Project Server 2013 Articles about Active Directory synchronization with the Project Server 2013 Resource Pool The following articles about Active Directory synchronization to your Project Web App instance's Enterprise Resource Pool in Project Server 2013 are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback. CONTENT Manage Active Directory Resource Pool synchronization in Project Server 2013 Supported Active Directory topologies for Project Server 2013 Enterprise Resource Pool synchronization Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server 2013 DESCRIPTION The Active Directory Resource Pool Synchronization settings in Project Server 2013 provide a method to quickly add Active Directory users as enterprise resources. This article describes the Active Directory topologies that are supported for synchronization with the Enterprise Resource Pool in Project Server This article describes the prescribed method to configure your Active Directory groups for synchronization with Project Server 2013 to add resources to the Enterprise Resource Pool.

361 Manage Active Directory Resource Pool synchronization in Project Server /13/ min to read Edit Online Summary: Use the Active Directory Resource Pool Synchronization settings in Project Server 2013 to quickly add Active Directory users as enterprise resources. Applies to: Project Server 2013 The Active Directory Resource Pool Synchronization settings are available through the Project Server 2013 Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies in Project Server In this article: Changes in Active Directory Resource Pool synchronization for Project Server 2013 User synchronization scenarios Requirements for Enterprise Resource Pool synchronization Configure Enterprise Resource Pool synchronization Schedule Enterprise Resource Pool synchronization Requirements for synchronizing the Enterprise Resource Pool with Active Directory users in a different domain SharePoint 2013 People Picker Keeping your Project Server 2013 resources synchronized with Active Directory is a good way to ensure that your resources are always current, and to automatically add the newest group's members to your list of resources. Project Server 2013 Active Directory Enterprise Resource Pool synchronization is used to create or update multiple Project Server enterprise resources at the same time. For example, new employees in your department can automatically be added as Project Server enterprise resources as long as they are in the Active Directory group selected for synchronization. Enterprise Resource Pool synchronization also updates enterprise resource properties with the most current data from Active Directory. For example, an employee's name and address may change because of marriage. As long as the change is made in Active Directory and the user is in the linked group, the change occurs in the user's Enterprise Resource properties when synchronization occurs. The Enterprise Resource Pool can be mapped with up to five Active Directory groups for synchronization. These Active Directory groups can contain nested groups whose members are also synchronized. Changes in Active Directory Resource Pool synchronization for Project Server 2013 It is important to note the following changes in Active Directory Resource Pool synchronization in Project Server 2013: No Project Server user accounts will be automatically created for resources that are added to the Enterprise Resource Pool through Active Directory synchronization.

362 You can synchronize up to five Active Directory groups with the Enterprise Resource Pool in Project Server User synchronization scenarios The following are the two most common actions that occur during the Enterprise Resource Pool synchronization process: A new Project Server enterprise resource can be created based on Active Directory membership By adding a new member to the Active Directory group that is being used for your Enterprise Resource Pool synchronization, you automatically also create a resource for this user in Project Server.. An existing Project Server user account's metadata (for example, name, address, and so on) can be updated if it has changed in Active Directory For example, if a resource's last name was changed in Active Directory, the Project Server 2013 Enterprise Resource Pool synchronization makes sure that the resource name is also changed in the Project Server Enterprise Resource Pool. The following table describes all Active Directory to Project Server 2013 Enterprise Resource Pool synchronization scenarios, as well as their corresponding actions: SCENARIO User exists in Active Directory and is a member of the Active Directory group mapped to the Enterprise Resource Pool. The user does not exist in Project Server User exists in Active Directory and is a member of the Active Directory group mapped to the Enterprise Resource Pool. The user exists in Project Server as a user, but not as a resource. User exists in Active Directory and is a member of the Active Directory group mapped to the Enterprise Resource Pool. The corresponding resource already exists in Project Server. User exists in Active Directory, but is removed from the Active Directory group mapped to the Enterprise Resource Pool. A user is marked as inactive in Active Directory. ACTION A new Project Server resource is created for this user. NOTE - A Project Server User Account is not created based on this synchronization. The Active Directory user needs to be added to a Project Server security group to create a user account. For more information, see Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server A new Project Server resource is created for this user, and is linked to the existing Project Server user account. The corresponding Project Server enterprise resource and user information is updated, if any updates were made to the user properties in Active Directory. The resource is not inactivated in Enterprise Resource Pool. The resource is not inactivated in the Enterprise Resource Pool. The corresponding Project Server User is not deactivated based on this synchronization. For more information, see Manage security group synchronization with Active Directory in Project Server. Requirements for Enterprise Resource Pool synchronization Before you perform this procedure, confirm the following: You have access to Project Server through Project Web App with an account that has the Manage Active Directory Settings and the Manage users and groups global settings enabled. The Service Application (SA) service account for the Project Server instance has Read access to all Active Directory groups and user accounts involved in the synchronization.

363 You can verify this account in the Service Application properties on the Service Application Administration page on the SharePoint Central Administration website. The identity under which the Queue service runs needs to have access to all the forest and domains in which it is expected to find users. The SharePoint 2013 People Picker must be able to resolve groups and access user information from Active Directory in order for Project Server 2013 Active Directory ERP synchronization to work. The People Picker allows you to search for Active Directory groups to which you want to synchronize to the ERP. The SharePoint 2013 People Picker is described in more detail later in this article. Configure Enterprise Resource Pool synchronization In the Project Web App Server Settings, you access the Active Directory Enterprise Resource Pool Synchronization page in which you can configure your settings. To configure Enterprise Resource Pool synchronization 1. In Project Web App, click the Settings icon, and then click Project Web App Settings. 2. On the Project Web App Server Settings page, in the Operational Policies section, click Active Directory Resource Pool Synchronization. 3. On the Active Directory Enterprise Resource Pool Synchronization page, in the Active Directory Group section, type the name or Service Account Manager (SAM) account of the active directory group or groups you want to synchronize with the Enterprise Resource Pool. If you are unsure of the group name, you can type part of the group name to display groups in Active Directory that contain the text string. The SharePoint 2013 People Picker provides the search functionality that displays the Active Directory groups you are looking for. To select a group from a remote forest, type the fully qualified domain name of the group (for example, group@corp.contoso.com). Note You can synchronize to a security or distribution group of any scope (Local, Global, or Universal). 4. You can enable inactive accounts to be reactivated if they are found in the Active Directory group during synchronization. To do so, in Sync options, select Automatically reactivate currently inactive users if found in Active Directory during sync. For example, an employee moves to a different role within their company and their Project Server user account is inactivated (they are removed from the Enterprise Resource Pool Active Directory group). The user later decides to go back to their old job, and they are added back to the Enterprise Resource Pool Active Directory group. If Automatically reactivate currently inactive users if found in Active Directory during sync is enabled, the user's account would be automatically reactivated upon synchronization. Note For this option to be available, it requires the October 2014 Cumulative Update for Project Server For more information about this update, see this Microsoft Project Support Blog post. 5. Click Save to save the settings and have synchronization scheduled to recur at the default setting (once a day at 12:00 AM). Click Save and Synchronize Now if you want to synchronize your Enterprise Resource Pool immediately, save your settings, and have synchronization scheduled to recur at the default setting.

364 You can check the status of the Enterprise Resource Pool synchronization by returning to the Active Directory Enterprise Resource Pool Synchronization page and reviewing the information in the Synchronization Status section. It contains information such as when the last successful synchronization occurred. If last synchronization failed for any reason, it will also post a timestamp of when it occurred if you wanted to search for more information in the ULS logs. Schedule Enterprise Resource Pool synchronization In Project Server 2013, scheduling synchronization of your enterprise resource pool with Active Directory groups is done through the Timer Job Status page in Central Administration. To schedule Enterprise Resource Pool synchronization 1. In Central Administration, click Monitoring. 2. On the Monitoring page, in the Timer Job section, click Check job status. 3. On the Timer Job Status page, find and then click Project Web App: Synchronization of AD with the Enterprise Resource Pool job for. For example: Project Web App: Synchronization of AD with the Enterprise Resource Pool job for 4. On the Edit Timer Job page, in the Recurring Schedule section, you can configure when the synchronization will run on a recurring basis. Under This timer job is scheduled to run, you can select one of the following options, based on your company's requirements: Minutes: Allows you to specify a frequency in which the job will run Every x minutes. Hourly: Allows you to specify an interval in which the job will randomly run Starting every hour between x minutes past the hour and no later than y minutes past the hour. Daily: Allows you to specify an interval in which the job will randomly run Starting every day between and no later than. Weekly: Allows you to specify in which the job will randomly run Starting every week between and no later than. Monthly: Provides two options: Allows you to specify an interval in which the job will randomly run By date: starting every month between and no later than. Allows you to specify an exact time of the month in which the timer job will run By day: starting every month <time of day, day of the week, and week of the month. For example, "12:00 AM on the first Sunday". 5. Click OK to save your configuration changes. Note You can click Run Now at any time to run the timer job immediately. Note that several options provide a period of execution time to run the job instead of an exact time or frequency. Selecting an option that provides a period of execution time allows the timer service to select a random time within the parameters specified in order to run the job on each application server. Using an option with a period of execution time is appropriate for high-load jobs which run on multiple servers in the farm. Running this type of job on all servers of the servers simultaneously might place an unreasonable load on the farm.

365 Requirements for synchronizing the Enterprise Resource Pool with Active Directory users in a different domain Imagine that you need to synchronize your Enterprise Resource Pool with Active Directory users that exist in a domain other than the one that Project Server 2013 is installed on. For example, your organization may acquire a new company, or your branch may need to add users from a different branch within your organization. In this scenario, a two-way trust relationship must exist between the domains in order for Active Directory users in one domain to synchronize with the Enterprise Resource Pool in a Project Server 2013 installation that exists on a different domain. Note Project Server 2013 does not support synchronizing your Enterprise Resource Pool or security groups with Active Directory users across different domains in which only a one-way trust relationship exists between domains. SharePoint 2013 People Picker As mentioned earlier in this article, Project Server 2013 can synchronize a user from Active Directory only if this user can first be found by the People Picker. People Picker will only be able to return users, groups, and claims in the following topologies: The domain in which your SharePoint Server 2013/Project Server 2013 farm is currently installed. A domain that has a two-way trust relationship with the domain in which your SharePoint Server 2013/Project Server 2013 farm is currently installed. By default, People Picker only returns users, groups, and claims from the domain on which SharePoint Server 2013 is installed. If you want People Picker to return query results from more than one forest or domain, you can create a two-way trust between the forests or domains. For both these cases, People Picker functions automatically, and no additional configuration is necessary. When two-way trusts are established, the People Picker automatically returns results found in the trusted domains. For example, the Contoso.com domain has a two-way trust with Litware.com and Fabrikam.com. The Project Server 2013 ERP synchronization defined in the Contoso.com domain in which the Project Server 2013 farm resides is configured to include Bob (from the Fabrikam.com domain) and Mindy (from the Litware.com domain). People Picker finds both groups in which both Bob and Mindy reside in their domain's Active Directory, the Project Server 2013 ERP synchronization will synchronize the group and both users successfully. If no trust or a one-way trust existed between the Contoso.com domain and the other domains, the users would not be able to synchronize to the Project Server 2013 ERP. See also

366 Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server 2013 Supported Active Directory topologies for Project Server 2013 Enterprise Resource Pool synchronization Manage security group synchronization with Active Directory in Project Server People Picker and claims providers overview (SharePoint 2013) Plan for People Picker in SharePoint 2013

367 Supported Active Directory topologies for Project Server 2013 Enterprise Resource Pool synchronization 12/13/ min to read Edit Online Summary: This article describes the Active Directory topologies that are supported for synchronization with the Enterprise Resource Pool in Project Server Applies to: Project Server 2013 When planning to synchronize your users from Active Directory groups to resources in your Project Web App Enterprise Resource Pool in Project Server 2013, it is important to understand that only certain Active Directory topologies are supported. This article describes the following topologies: Supported topologies - Topologies that are supported with the Project Server 2013 RTM build. Additional topologies - Topologies that are supported with the Project Server 2013 March Cumulative Update. Unsupported topologies - Topologies that will not be supported. Supported topologies The following topologies are supported when synchronizing your users and groups from Active Directory to your Enterprise Resource Pool for your Project Web App instance in Project Server Note that some topologies will require you to install the Project Server 2013 March Cumulative Update to your Project Server 2013 environment in order to be supported. Single Domain topology In the single domain topology, Active Directory and Project Server 2013 servers all reside in the same domain. This is the simplest of topologies for Active Directory synchronization to your Enterprise Resource Pool or security groups, since this topology does not require the configuration of trusts between domains. Additional topologies The following topologies are also supported, but require the installation of the Project Server 2013 March Cumulative Update. These topologies include: Single Forest Parent-Child Trust topology Single Forest Tree-Root Trust topology Forest Trust topology

368 External Trust topology Note Unless this update is installed, your Project Server 2013 environment will only support the single domain topology. For more information about the Project Server 2013 March 12, 2013 Cumulative Update, see Description of the Project Server 2013 update: March 12, Single Forest Parent-Child Trust topology Important This topology is not supported for Active Directory synchronization with the RTM build of Project Server It is only supported by installing the Project Server 2013 March 12, 2013 Cumulative Update to your Project Server 2013 environment. In this single forest topology, a child domain is created off of the parent domain. By default, the relationship between the child and parent domain is automatically two-way and transitive. This relationship ensures that users in the corp.contoso.com domain can be synchronized with the Project Server 2013 Enterprise Resource Pool in usa.corp.contoso.com. Additionally, if you created another child domain off of the usa.corp.contoso.com domain and host an Active Directory there, its users and groups would be able to be resolved by Project Server 2013 hosted in any other domain in the same tree. Single Forest Tree-Root Trust topology Important This topology is not supported for Active Directory synchronization with the RTM build of Project Server It is only supported by installing the Project Server 2013 March 12, 2013 Cumulative Update to your Project Server 2013 environment. In this single forest topology, when you create a new domain within an existing forest, you create a tree root trust between the new domain and the rest of the forest. By default, this relationship ensures that users in a domain in the tree (for example, usa.corp.contoso.com) can be synchronized to the Project Server 2013 Enterprise Resource Pool if it resided in the new domain (for example, corp.litware.com). Tree-root trusts are always two-way and transitive, so the synchronization could also occur successfully if the Project Server 2013 Enterprise Resource Pool resided in usa.corp.contoso.com, and the Active Directory users resided in the corp.litware.com domain.

369 In this topology above, Project Server 2013 trusts the Active Directory domain through its own root trust with the forest root domain, and then through the parent child trust between the forest root domain and the domain that contains the Active Directory. Forest Trust topology Important This topology is not supported for Active Directory synchronization with the RTM build of Project Server It is only supported by installing the Project Server 2013 March 12, 2013 Cumulative Update to your Project Server 2013 environment. In this multi-forest topology, two forests exist in which Project Server 2013 resides in one forest, and the Active Directory users reside in another. A forest trust needs to be created between forest root domains for each forest in order for the Project Server 2013 Enterprise Resource Pool to successfully synchronize with Active Directory groups and user in the other forest. Forest trusts are transitive, so any domain within one forest will trust any domain within the other forest. You are not required to setup individual trusts, although if your topology is complex you may need to set up some shortcut trusts. For more information about creating a shortcut trust, see Create a shortcut trust.

370 In the topology graphic above, a forest trust is established between the Contoso and Fabrikam forests. The domain in which Project Server 2013 resides (corp.litware.com) and the domain containing the Active Directory users (usa.corp.fabrikam.com) trust each other because of the transitivity of the forest trust. This trust can be configured to be either one-way or two-way. External Trust topology Important This topology is not supported for Active Directory synchronization with the RTM build of Project Server It is only supported by installing the Project Server 2013 March 12, 2013 Cumulative Update to your Project Server 2013 environment. In this multi-forest topology, you allow synchronization with users in a different forest by creating an external trust between the domain hosting Project Server 2013 and the domain hosting the Active Directory. This is useful if you need to synchronize users who reside in only a single domain, but not the whole forest. In the topology graphic above, Project Server 2013 can synchronize with groups and users in the usa.corp.fabrikam.com domain. Since an external trust is non-transitive, Project Server 2013 will not be able to synchronize with groups or users from any other domain in the Fabrikam forest. Unsupported topologies All topologies not mentioned in this article as supported topologies are not supported. This includes (but not limited to):

371 Topologies using Realm trusts Topologies without properly configured trusts See also Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server 2013 Manage Active Directory Resource Pool synchronization in Project Server 2013 Manage security group synchronization with Active Directory in Project Server

372 Best practices to configure Active Directory groups for Enterprise Resource Pool synchronization in Project Server /13/ min to read Edit Online Summary: This article describes the prescribed method to configure your Active Directory groups for synchronization with Project Server 2013 to add resources to the Enterprise Resource Pool. Applies to: Project Server 2013 When configuring synchronization between the Enterprise Resource Pool (ERP) and Active directory groups in Project Server 2013, a key consideration is that after being added as a resource to Project Server, you still need to add the resource as a user in order for the resource to use Project Web App. Unlike the previous version, in Project Server 2013 users accounts are not automatically created for resources that are added to the Enterprise Resource Pool through Active Directory synchronization. This article describes a best practice in which you can configure your Active Directory groups for security group synchronization as well as ERP synchronization in order to add user accounts for your resources. Active Directory group configuration for ERP and security group synchronization It is important to note the following when planning to configure your active directory groups for synchronization with the ERP and with security groups in Project Server 2013: You can synchronize up to five Active Directory groups with the Enterprise Resource Pool. You can only synchronize one Active Directory group with each security group. For example, only one Active Directory group can be configured to synchronize with the default Project Managers security group. The following graphic displays the method we suggest to configure your Active Directory groups to add your Project Server 2013 users both as resources and as users to their appropriate security groups. In the graphic above, Active Directory is configured to contain a single "ERP Group" that also contains nested Active Directory groups for Team Members, Project Managers, and Resource Managers. Although you can

373 synchronize up to five Active Directory Groups with the Enterprise Resource Pool, we synchronize only the single ERP group, which would include all users contained in the subgroups. User 1, User 2, User 3, User 4, User 5, and User 6 would all be synchronized to the Enterprise Resource Pool in Project Server Note You can configure Active Directory synchronization to the Project Server 2013 ERP through the Active Directory Resource Pool Synchronization page in the Operational Policies section of Project Web App Server Settings. For more information, see Manage Active Directory Resource Pool synchronization in Project Server In order to add the resources as users in Project Server 2013 to give them Project Server user accounts, we also need to synchronize them from Active Directory to their appropriate security group in Project Server In the graphic above, each of the nested sub-groups in the ERP Group are synchronized with their appropriate security group in Project Server For example: The Team Member group in Active Directory is synchronized with the Team Members security group in Project Server The Project Managers group in Active Directory is synchronized with the Project Managers security group in Project Server The Resource Managers group in Active Directory is synchronized with the Resource Managers security group in Project Server Note You can configure Active Directory synchronization to Project Server 2013 security groups through the Manage Groups page in the Security section of Project Web App Server Settings. For more information, see Manage security group synchronization with Active Directory in Project Server. A benefit of this configuration is that any changes to Active Directory can be made in a single location, and will be reflected in both the Enterprise Resource Pool and in security group. For example, if the Team Member "User 1" gets married and her last name is updated in Active Directory, the change in user properties will be reflected in both the Enterprise Resource Pool and the Project User Account when both groups are synchronized with the Active Directory group. Another benefit is that it prevents confusion that can be associated if a user is in two or more active directory groups that are synchronized with the ERP. See also Manage Active Directory Resource Pool synchronization in Project Server 2013 Manage security group synchronization with Active Directory in Project Server Supported Active Directory topologies for Project Server 2013 Enterprise Resource Pool synchronization

374 Manage connected SharePoint sites in Project Server /13/ min to read Edit Online Summary: The Connected SharePoint Sites page in Project Web App Settings lets you manage project sites in Project Server Applies to: Project Server 2013 The Connected SharePoint Sites setting is available through the Project Web App Server Settings page in the Operational Policies section. For more information about related administrative settings, see Operational Policies in Project Server Configure the Project Sites settings You can do the following through the Connected Project Sites page: Create a new project site Edit a project site address Synchronize Delete a project site Go to Project Site Settings The Create Site settings Create Site lets you create a new project site for your project if you did not create one when the project was originally published to Project Server You can view the Project Sites list on the Connect SharePoint Sites page to determine whether a project has an existing site. A project without a project site does not have a corresponding URL next to it in the Site Address column. To create a project site 1. In Project Web App, click the Setting icon, and on the menu click Project Web App Settings. 2. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites. 3. On the Connected SharePoint Sites page, from the Project Name list, select a project for which you want to create the project site. 4. Click Create Site. The Create Project Site dialog box appears. 5. In the Web Application list, select the web application that you want for the project site. 6. In the Site URL field, verify the site URL for the project site. You can edit the site URL information, if necessary. The site URL is appended to the web application name to provide the destination URL (as seen in the Destination URL field). 7. Click OK. The project site you created now appears next to the project name that you selected in step 2.

375 The Edit Site Address settings Edit Site Address lets you edit the destination URL for a project site to point to a new site address. Changing the site address information breaks the existing link between the project and the existing project site. You can then enter the information for the new project site. Note Before changing the project site URL for a project, be sure to provision a new project site with a new site template. To edit a site address for a project site 1. In Project Web App, click the Setting icon, and on the menu click Project Web App Settings. 2. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites. 3. On the Connected SharePoint Sites page, from the Project Name list, select a project for which you want to edit the project site information. 4. Click Edit Site Address. The Edit Site Address dialog box appears. 5. To change the project site URL to the new URL, select Type a new SharePoint site URL. Select the Web Application in which the new site is located and enter the Site URL for the new site. 6. Click Test URL to verify whether the new project site URL can be opened. 7. You optionally can unlink the existing SharePoint site from the project through the Edit Site Address dialog box. To do this, click Unlink the SharePoint site from the project. Note Unlinking a SharePoint Tasks List project from a project site enables the enterprise project feature for the project. 8. Click OK. The project site URL for the project you selected in step five is changed to the new URL. The Synchronize settings Note The Synchronize setting is only available in Project Permission Mode. This setting is not available in SharePoint Permission Mode. Synchronize lets you manually synchronize the project site's users, permissions, and other Project Server-related information between Project Server 2013 and the Web server that is running SharePoint Server If you want to automatically run synchronization for your project sites, see the Automatic Provisioning option that is available in Project Site Provisioning Settings (Project Server 2013 settings). To synchronize your project site information between Project Server and SharePoint Foundation 1. In Project Web App, click the Setting icon, and on the menu click Project Web App Settings. 2. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites.

376 3. On the Connected SharePoint Sites page, from the Project Name list, select a project for which you want to synchronize your project site information between Project Server 2013 and SharePoint Server Click Synchronize. Note Synchronization will automatically recur at the default schedule of every one minute. You can choose to change the default schedule synchronization setting by configuring the Project Server: Synchronization of SharePoint Server permission to Project Web App permissions timer job in Central Administration. To change the synchronize schedule 1. In Central Administration, click Monitoring. 2. On the Monitoring page, in the Timer Job section, click Review job definitions. 3. On the Job Definitions page, find and click Project Server: Synchronization of SharePoint Server permission to Project Web App permissions for job. For example: Project Server: Synchronization of SharePoint Server permission to Project Web App permissions job for 4. On the Edit Timer Job page for the job, in the Recurring Schedule section, you can specify when the synchronization will run on a recurring basis. Under This timer job is scheduled to run, you can select one of the following options, based on your company's requirements: Minutes: Allows you to specify a frequency in which the job will run Every x minutes. Hourly: Allows you to specify an interval in which the job will randomly run Starting every hour between x minutes past the hour and no later than y minutes past the hour. Daily: Allows you to specify an interval in which the job will randomly run Starting every day between and no later than. Weekly: Allows you to specify in which the job will randomly run Starting every week between and no later than. Monthly: Provides you two options: Allows you to specify an interval in which the job will randomly run By date: starting every month between and no later than. Allows you to specify an exact time of the month in which the timer job will run By day: starting every month <time of day, day of the week, and week of the month. For example, 12:00 AM on the first Sunday. 5. Click OK to save your configuration changes. Note You can click Run Now at any time to run the timer job immediately. The Delete Site settings Delete Site lets you permanently remove a project site and its content.

377 Important Before you proceed, verify that you want to permanently remove a site and its content. Deleted project sites are not recoverable. Note When a project site is deleted for a SharePoint Tasks List project, the enterprise project feature is enabled for the project. To delete a project site 1. In Project Web App, click the Setting icon, and on the menu click Project Web App Settings. 2. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites. 3. On the Connected SharePoint Sites page, from the Project Name list, select a project for which you want to delete a project site. 4. Click Delete Site. A message box appears that asks you to confirm whether you want to delete the project site. It also warns you that you will also be deleting all documents, issues, risks, and deliverables that are associated with the site. 5. Click OK to proceed with deleting the site. Click Cancel if you no longer want to delete the site. 6. If you clicked OK, the project site is deleted and no longer appears next to the project it was associated with on the Project Sites page. Go to Project Site Settings Go to Project Site Settings lets you go directly to a project site's site settings page where the sites administration settings are located. From the Site Settings page, you can make changes to the site, such as add or remove users, add Web Parts to the site, customize the site's look and feel, and many others. To go to the Site Settings page for a project site 1. In Project Web App, click the Setting icon, and on the menu click Project Web App Settings. 2. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites. 3. On the Connected SharePoint Sites page, from the Project Name list, select a project for which you want to view the Project Site settings page. 4. Click Go to Project Site Settings. 5. The Site Settings page for the selected project site opens. You can make changes to the site settings from this page.

378 Additional Server Settings (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: The Additional Server Settings page is part of operation policies for Project Server 2013 Server Settings. Applies to: Project Server 2013 The Additional Server Settings page is available in the Operational Policies section of the Project Server 2013 Server Settings page. The Additional Server Settings are in SharePoint Central Administration and can only be accessed if you are a farm administrator. For more information about related administrative settings, see Operational Policies settings in Project Web App. The Additional Server Settings page in Project Server 2013 Server Settings lets you configure: Project Professional Versions (Project Server 2013 settings) Enterprise Settings (Project Server 2013 settings) Currency Settings (Project Server 2013 settings) Resource Capacity Settings (Project Server 2013 settings) Resource Plan Work Day (Project Server 2013 settings) Exchange Server Details (Project Server 2013 settings) Task Mode Settings (Project Server 2013 settings)

379 Project Professional Versions (Project Server 2013 settings) 12/14/ min to read Edit Online Summary: Use the Project Professional Versions setting to define which builds of Project Professional 2013 can connect to Project Server Applies to: Project Server 2013 Project Professional Versions is a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Project Professional Versions Project Professional Versions lets you specify which versions (build numbers) of the Project Professional client will be able to connect to your Project Server 2013 environment. This setting lets you ensure that Project Professional client connections to the server are all at a required base level. For example, if you recently updated both Project Server 2013 and Project Professional 2013 to the same cumulative update, you can verify that all clients that connect to the server are at least at this level by entering the build number. All Project Professional 2013 clients that have not been updated to the specified cumulative update or a newer version will be unable to connect. Note Project Professional 2013 is the only Project Professional client that can connect to Project Server To configure the Project Professional Versioning setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Project Professional Versions setting. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Project Professional Versions setting, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. On the Additional Server Settings page, in the Project Professional Versions section, type the build number of each Project Professional version that you want to connect to Project Server Use a comma as a separator between multiple version numbers. Versions older than the lowest build number that you enter will be unable to connect to your Project Server 2013 environment. 7. Click Save. To find your Project Professional 2013 build number 1. In Project Professional 2013, click the File tab.

380 2. On the left pane, click Account. 3. On the Account page, in the Product Information section, click About Microsoft Project. 4. On the About Microsoft Project page, the build number is located at the top of the page (for example, ).

381 Enterprise Settings (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Learn to use the Enterprise Settings options in SharePoint Central Administration to provide additional flexibility for your Project Server 2013 projects. Applies to: Project Server 2013 Enterprise Settings options are a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Enterprise Settings Enterprise Settings lets you determine whether Project Server 2013 allows for projects to have the following capabilities: Allow master projects to be saved and published (By default, this option is enabled.) Enabling this setting enables master projects to be used in Project Server Master projects are projects that contain sub-projects, and they usually contain tasks that are dependent on one another. Check with your Project Management Office to determine whether your organization prohibits the use of master projects. Allow projects to use local base calendars Enabling this settings lets users not only use enterprise base calendars that are on the system for their enterprise projects, but to also use local base calendars that users create. Having this setting disabled (which is the default) restricts users to using only enterprise base calendars that are on the system for their projects. Restricting the users to enterprise calendars gives you more control by preventing problems that can occur when projects use local base calendars that contain conflicting data. For example, a project that uses a local base calendar that differs from an enterprise calendar (for example, July 4 as a work day versus a holiday) can lead to faulty calculations and other issues. To configure the Enterprise Settings 1. In SharePoint Central Administration, click Application Management. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Enterprise Settings options. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Enterprise Settings options, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. On the Additional Server Settings page, in the Enterprise Settings section: 7. Select Allow master projects to be saved and published to Microsoft Project Server 2010 if you want to enable this setting. (By default, it is enabled.) 8. Select Allow projects to use local base calendars if you want to enable this setting (By default, this option is cleared.) 9. Click Save.

382 Currency Settings (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Currency Settings in Project Server 2013 to set the default currency for projects. Applies to: Project Server 2013 The Currency Settings are part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Currency Settings Through the currency setting, you can select the default currency setting for projects that are published to the server. (This is used for reports and the default view for new projects.) The default value is based on the default currency of the language that is used for the Project Web App instance. You can also select the currency settings for publishing: Allow projects to be published in various currencies Select this option if your organization uses multiple currencies for costs within projects. (This is the default setting). Enforce that projects are published in the server currency Select this option if your organization only uses a single currency for costs within projects. The currency that is used is the one selected as the default server currency. To configure the Currency Settings 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Project Professional Versions setting. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Project Professional Versions setting, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. On the Additional Server Settings page, in the Currency Settings section, select one of the following currency options: Allow projects to be published in various currencies (Selected by default). Enforce that projects are published in the server currency If you select Enforce that projects are published in the server currency, you see a message. This message box warns you that the change is only be enforced on all successive projects that are published to the server. All projects that are not using the default server currency must be changed to the default currency and republished. 7. Click OK. All projects published to the server that are using a currency that conflicts with the server currency will be displayed in the Currency Settings section of the page in the Project in conflict with the server currency

383 list. You can use this as a reference to note which projects have to have their currency changed to the server currency. 8. Click Save. Change currency option for a project Use the following procedure in Project Professional 2013 to change the currency settings for a project. You can use this procedure to do the following: Select the currency for a specific project if the currency setting lets you use multiple currencies. Change the currency setting on a project to the server currency if the currency setting only lets you use the server currency. To change the currency for a project in Project Professional Open Project Professional 2013 and log on to Project Server Check out and open a project from Project Server Click File, and then click Options. 4. On the Project Options page, click Display. 5. On the Display page, in the Currency options for this project section, select the currency and then the currency format (symbol, placement, and decimal digits) that you want to use for this project. 6. Click OK. 7. Click File, and then click Save to save the project. 8. Click File, and then click Publish to publish the project. See also Additional Server Settings (Project Server 2013 settings)

384 Resource Capacity Settings (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Resource Capacity Settings in Central Administration to help you calculate resource availability in Project Server Applies to: Project Server 2013 The Resource Capacity Settings are a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Resource Capacity Settings Resource Capacity Settings are used to calculate your resources' availability for work over a specified time range. Your resources' capacity data for the specified time range is stored on the Reporting database, and it is updated daily through a processing job that is run at a time that you specify in the settings. You are able to set the Active capacity view by entering a time range in relative terms months in the past, and months in the future where the current date is a relative starting point. You can view your resources' availability for work through the Resource Center in Project Web App. The default Active capacity view settings are "1" month behind and "12" months ahead. This means that in the Resource Center you can view a resource's future availability for up to 12 months from the current date, and you can view utilization over the last month. By increasing the Month ahead setting, you get more capacity computed for future periods. For example, imagine that a company plans for new projects later in the year and wants to forecast the capacity for resources from 12 months to 24 months. Some customers might want to increase the Months behind value to get an accurate report of work completed in the past (for example, to account for any users who might report time long after the work is completed). Note that increasing either value also increases the time it takes for the daily processing job to run. To configure Resource Capacity Settings 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Resource Capacity settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Resource Capacity settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. On the Additional Server Settings page, in the Resource Capacity Settings section, for Active capacity view, enter the following: 7. In the Months behind field, enter the number of months in the past that you want resource data to be calculated from. 8. In the Months ahead field, enter the number of months in the future that you want resource data to be

385 calculated from. 9. Click Save. Resource Capacity information will be processed daily at 1:00 AM by default. See also Additional Server Settings (Project Server 2013 settings)

386 Resource Plan Work Day (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Resource Plan Work Day settings in Central Administration to set full-time equivalency for resources in Project Server Applies to: Project Server 2013 Resource Plan Work Day is a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Resource Plan Work Day Resource Plan Work Day lets you specify the length of a work day ("full-time equivalents" or FTE) for all resources in your resource plan. This value can be calculated from the resource's base calendar or can be manually entered as a value. To configure the Resource Plan Work Day setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Resource Plan Work Day setting. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Resource Plan Work Day setting, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. On the Additional Server Settings page, in the Resource Plan Work Day section, for Calculate resource fulltime equivalent from, select one of the two options: Resource base calendars Use this option if you want the full-time equivalents to be calculated from each resources base calendar. This is the default option. Hours per day Use this option if you want to specify the full-time equivalents for your resources in the resource plan. After selecting this option, enter the value (in hours) of the standard work day for your organization. Note that this value is used for all resources in the resource plan. 7. Click Save. See also Additional Server Settings (Project Server 2013 settings)

387 Exchange Server Details (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Exchange Server Details setting in SharePoint Central Administration to enable or disable Microsoft Exchange Server integration with Project Server Applies to: Project Server 2013 Exchange Server Details is a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. An additional requirement for this feature is that the Project queue is required to run under a mail-enabled user account. Exchange Server Details The Exchange Server Details page allows you to enable or disable Microsoft Exchange Server integration with Project Server When enabled, it allows you to synchronize your resources out-of-office time between Exchange Server and Project Server This is done at an individual resource level in the resource properties page. Disabling the setting will disable Microsoft Exchange integration with Project Server. This setting is disabled by default. To configure the Exchange Server Details setting 1. In SharePoint Central Administration, click General Application Settings. 2. On the General Application Settings page, in the Project Web App settings section, click Manage. 3. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Project Professional Versions setting, and click Manage. 4. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 5. On the Additional Server Settings page, in the Exchange Server Details section, click Synchronize Out of Office calendars if you want to automatically synchronize out-of-office time in resource calendars between Project Server 2013 and Exchange Server 2007 with Service Pack 1, Exchange Server 2010, or Exchange Server Click Save. See also Additional Server Settings (Project Server 2013 settings)

388 Task Mode Settings (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Task Mode Setting in SharePoint Central Administration to define the default task mode used to schedule tasks in Project Server Applies to: Project Server 2013 Task Mode Settings is a part of the Additional Server Settings in the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these setting are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Task Mode Settings Task Mode Settings let you select the default mode in which tasks are scheduled: manually or automatically. Additionally, if you select the default setting ( Manually Scheduled), you can also configure if you want task to be published to team members. Manually scheduled tasks (also known as "User-Controlled Scheduling") were introduced in previously in Project Server In this mode, when a new task is created, the scheduling engine is ignored and Project Server 2013 creates the task without a duration, start date, or finish date. (These values can be entered manually.) It can be useful for scheduling tasks with hard dates that are difficult to move (for example, training). To configure the Task Mode setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Task Mode setting. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Task Mode setting, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Additional Server Settings. 6. In the Task Mode Settings section: 7. Select Manually Scheduled tasks can be published to team members (which is enabled by default) if you want to allows project managers to publish their manually scheduled task to team members. 8. For Default task mode in new projects, select one of the two following settings: Manually Scheduled You have to enter duration, start, and finish dates for your tasks. By default, this option is selected. Automatically Scheduled The scheduling engine automatically calculates durations and start dates and finish dates for your tasks. 9. Select Users can override default in Project Professional (which is enabled by default) if you want to enable your Project Professional 2013 users to override the default task mode settings that you selected. 10. Click Save.

389 See also Additional Server Settings (Project Server 2013 settings)

390 Server Side Event Handlers (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Server Side Event Handler page in SharePoint Central Administration to associate event handlers with Project Server 2013 server side events. Applies to: Project Server 2013 The Server Side Event Handler settings are available through the Project Server 2013 Server Settings page in the Operational Policies section. In Project Server 2013, these settings are available in SharePoint Central Administration. To access and configure this setting, you must be a farm administrator. Configure Server Side Event Handlers Project Server 2013 provides public events that enable development of custom processes such as adding and enforcing business rules, validation, data processing, notification services, and workflow. These custom processes are written as server-side event handlers by developers in an organization and can be associated to Project Server 2013 events through the Server Side Event Handlers page in Project Web App Server Settings. For example, developers in your organization can create an event handler that starts a custom workflow. Through the Server Side Event Handlers page, you can associate that event handler with the Project Published event so that a workflow starts when the event occurs. For more information about Project Server event handlers, see the MSDN article, How to: Create a Project Server Event Handler and Log an Event To associate an event handler with a server-side event 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Server Side Event handler settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Server Side Event handler settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Server Side Event Handlers. 6. On the Server Side Event Handlers page, in the Events list, find the event that you want to associate your new event handler with, and then click the Event Source listed next to the Event Name (for example, click the Project event source for the Published event name). In the Event Handlers section, the Event Source and Event Name should be populated with the event that you selected. Any event handlers that are currently associated with the event appear in the Event Handlers list. 7. Click New Event Handler. 8. In the New Event Handler page, enter the following information for the event handler that you want to associate with the selected event: 9. In the Display Information section, enter the event handler name. You can also optionally enter a

391 description of the event handler. 10. In the System Information section, in the Assembly Name field, enter the full name of the strongly named event handler assembly. For example: TestCreatingProject, Version= , Culture=neutral, PublicKeyToken=92978aaaab03ff In the Class Name field, enter the fully qualified name of the class that implements the event handler functionality. For example: Microsoft.SDK.Project.Samples.TestCreatingProject.CheckProjectDepartment. 12. In the Order field, provide the order number of the event handler. If it is the only event handler associated with the event, enter1. If there are multiple event handlers associated with the event, enter the order number in which this event handler will be executed. 13. In the Endpoint URL field, enter the Windows Communication Foundation (WCF) Endpoint URL. If you are adding a legacy on-premises event handler, you can leave this field blank. 14. Click Save.

392 Project Site Provisioning Settings (Project Server 2013 settings) 12/14/ min to read Edit Online Summary: Use the Project Site Provisioning Settings in Central Administration to configure the automatic creation of project sites for projects in Project Server Applies to: Project Server 2013 Project Site Provisioning Settings are part of the Operational Policies section of Project Server 2013 Server Settings. In Project Server 2013, these settings are available in SharePoint Central Administration. To access this setting, you must be a farm administrator. Configure Project Site Provisioning Settings The Project Site Provisioning Settings page let you configure settings for the project sites that are created for projects. You can configure the following settings: Site URL Default Site Properties Site creation settings Site URL The Site URL settings let you set the default Web application in which your project sites are created. The default site URL information on this page is based on the information that is provided during the provisioning of the Project Web App instance. To specify site URL information 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Site Provisioning settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Site Provisioning settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings. 6. On the Project Site Provisioning Settings page, in the Site URL section, specify a default Web application that your project sites will be created from. Select the Web application from the Default Web application menu. 7. In the Site URL field, type the URL path (for example,pwa). 8. Select Restrict Project site creation to the default site collection if you only want project sites to be created in the site URL settings you specify. 9. Click Save. Default Site Properties

393 The Default Site Properties settings let you select the default site template language that will be used to create your project sites. To configure default site properties for your Project Sites 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Site Provisioning settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Site Provisioning settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings. 6. On the Project Site Provisioning Settings page, in the Default Site Properties section, select the default language for your project sites from the Default site template language drop-down list. Note The languages available to you in the Default site template language drop-down list are:> The language of your baseinstallation of Project Server 2013.> The language of any installed Project Server 2013 language packs.> For example, if you install the Project Server 2013 Spanish language pack on a Project Server 2013 English base installation, you can choose English or Spanish from the Default site template language drop-down menu. Selecting one or the other will determine the default language the Project Web App user interface will display in for newly provisioned instances of Project Web App. 7. Click Save. Site creation settings The Site creation settings lets you indicate whether you want to have Project Server 2013 create project sites for projects when the projects are newly published to the server. The settings can be configured to not create a project site. Additionally, you could provide users the option select either option. Note If you choose not to create a site, you can create a site for your project later through the Project Sites page in the Project Web App Server Settings page. For more information, see Manage connected SharePoint sites in Project Server To configure the site creation setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Site Provisioning settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Site Provisioning settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Project Site Provisioning Settings. 6. On the Project Site Provisioning Settings page, in the Site creation settings section, select one of the three

394 Provisioning mode options: Automatically create a project site on first publish Allow users to choose Do not create a site 7. Click Save. See also Manage connected SharePoint sites in Project Server 2013

395 Bulk Update Project Sites (Project Server 2013 settings) 12/13/ min to read Edit Online Summary: Use the Bulk Update Project Sites settings in SharePoint Central Administration to change site path information for project sites in Project Server Applies to: Project Server 2013 Bulk Update Project Sites are part of the Operational Policies section of Project Server 2016 Server Settings. In Project Server 2016, these settings are available in SharePoint Central Administration. To access this setting, you must be a farm administrator. Configure the Bulk Update Project Sites Setting The Bulk Update Project Sites page allows you to change site path information for project sites in one Web application to a different one (for example, when migrating). It allows you to break the original links between projects and their corresponding project sites in one site collection and then relink to the new project sites in the new site collection. Update Site Paths Update Content Types Project Site Permissions Update Site Paths The Update Site Paths setting lets you break links between projects and project sites that are contained in one site collection and relink with the new project sites in a different site collection. To update project site paths to a new site collection 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Bulk Update Project Sites settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Bulk Update Project Sites settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites. 6. On the Bulk Update Project Sites page, in the Update Site Paths section, for Previous Site Path: 7. Select the Web application for your project sites that you want to break the link to. If you are migrating project sites on the same server, the Web application that you need to select may appear as a URL. If you are migrating projects sites from a different server, the Web application you need to select may appear as a globally unique identifier (GUID). 8. In the Site URL field, type the site URL information (for example, PWA). 9. For New Site Path:

396 10. Select the Web application that contains the project sites that you want to link to (for example, In the Site URL field, type the site URL information (for example, PWA). 12. Click Save. Update Content Types The Update Content Types setting allows you to ensure that when you migrate content from one farm to another, the content types of Project Issues, Risks, and Documents are updated in the new location so that item links remain functional. To enable the Update Content Types setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Bulk Update Project Sites settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Bulk Update Project Sites settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites. 6. On the Bulk Update Project Sites page, in the Update Content Types section, select Update Content Types. 7. Click Save. Project Site Permissions The Project Site Permissions setting allows you to synchronize permissions to the Project Sites while updating the site paths. This allows users to immediately access their project sites. Note For the Project Site Permissions setting to be enabled, the Project Site Permissions setting must also be enabled on the Project Site Provisioning page. To enable the Synchronize site permissions setting 1. In SharePoint Central Administration, click ** Application Management**. 2. On the Application Management page, in the Service Application section, click Manage Service Applications. 3. On the Service Applications page, click the Project Application Service that contains the Project Web App instance for which you want to access the Bulk Update Project Sites settings. 4. On the Manage Project Web Apps page, click the drop-down menu for the PWA instance for which you want to access the Bulk Update Project Sites settings, and click Manage. 5. On the Server Settings page, in the Operational Policies section, click Bulk Update Project Sites. 6. On the Bulk Update Project Sites page, in the Project Site Permissions section, click Synchronize site permissions. 7. Click Save.

397 See also Operational Policies (Project Server 2013)

398 Manage Queue Settings for Project Web App 12/13/ min to read Edit Online Use the Manage Queue Settings for Project Web App page to configure Project Queue settings in Project Server Applies to: Project Server 2013 In Project Server 2013, Queue settings are no longer applicable to individual Project Web App instances, but now apply to all Project Web App instances that are created in the Project Service Application. Additionally, because the Queue is now located at the Project Service level, the Manage Queue Settings page can be accessed in the SharePoint Central Administration website instead of Project Web App. Important Project Server 2013 Queue performance has increased significantly from the previous version because of many changes that were implemented for this release. The default values are the recommended queue settings for optimal performance. Before you begin If you are sure you need to change the default Queue settings, you need to be at least a Service Application Administrator for the Project service application. This is the least privileged permission level required. The Manage Queue Settings page can be accessed in the Project Service Application page in Central Administration. Use the following procedure to access the Manage Queue Setting page in the Project Service Application page: To access the Manage Queue Setting page 1. In Central Administration, in the Application Management section, under Service Applications, click Manage service applications. 2. On the Manage service application page, click the name of the Project service application. 3. On the Manage Project Web Apps page, click Manage Queue Settings for Project Web App. Important Verify with your Project Server Administrator before you make changes to your default Queue settings. Changes will affect the way that queue jobs are processed, and will affect all Project Web App instances that were created under the Project Service Application. Queue settings The Manage Queue Settings for Project Web App page allows you to change the following Queue settings: Maximum Degree of Concurrency Retry Interval Retry Limit SQL Timeout Cleanup Age Limit for Successful Jobs

399 Cleanup Age Limit for Unsuccessful Jobs Bookkeeping Interval Queue Timeouts Important The SQL Retry Interval and SQL Retry Limit settings that display on this page are obsolete in Project Server 2013 and will be removed in a future update. Do not use these settings. Maximum Degree of Concurrency Because the Queue is multithreaded, multiple jobs that are sent to the queue can be processed at the same time. The Maximum Degree of Concurrency setting limits the number of jobs that can be processed at the same time, by setting the maximum number of job processor threads that are available in the Queue. The valid range is 1 through 10, with a default value of 4. In Project Server 2013, the value for this setting acts as a multiplier of the number of cores on the application server. For example, if your application server is using a dual-core processor, and the Maximum Degree of Concurrency is set at the default value of 4, the maximum number of jobs that can be processed at the same time is 8. If you have multiple application servers, this setting applies to each server on which the Project Server application service is running. For example, if you have two application servers that have dual-core processors, and the Maximum Degree of Concurrency is set at the default value of 4, each server can process up to 8 jobs at the same time. Retry Interval (in milliseconds) The Retry Interval setting lets you set the length of time (in milliseconds) between retries for jobs that have failed because of transient issues, such as a SQL time-out. If the processing job fails, instead of failing the job, the Queue will wait for the time set by the Retry Interval value, and then will retry the job. The valid range is 0 (immediate retry) to (1 minute), with a default value of 1000 (1 second). Retry Limit The Retry limit setting lets you set the maximum number of times a failed processing job will be retried. If the job does not process because of transient issues, such as a SQL time-out, instead of failing the job, the Queue will retry the job. The number of retries attempted is set by the value entered for this setting. Note that the amount of time between retries is set by the Retry Interval setting. The valid range is 0 (no retries) to 100. The default value is 5. SQL Timeout (in seconds) The queue makes SQL calls for retrieving and executing jobs. This SQL Timeout setting lets you set the time-out value (in seconds) for these calls. If any job fails because of a SQL Timeout error, you can increase the value for this setting and retry the job. The valid range is 30 to (one day), with a default value of 1800 (30 minutes). Cleanup Age Limit for Successful Jobs The Cleanup Age Limit for Successful Jobs setting lets you configure when a job that has been completed successfully is removed from the system. Successfully completed jobs can be removed from the system through the Queue Cleanup job, which can be configured so that it removes successfully completed jobs after they reach a certain age threshold. You can configure this setting by entering the value (in hours) in the Cleanup Age Limit for Successful Job field. The value that you enter configures the queue to delete the job when the Queue Cleanup job is scheduled to run, only if the age of the successfully created job is equal to or greater than that value. The valid range for this setting is 1 hour through 100,000 hours. The default value for this setting is 24 hours (one day). Cleanup Age Limit for Non-Successful Jobs The Cleanup Age Limit for Non-Successful Jobs setting lets you configure when a job that has completed in an unsuccessful state is removed from the system. You can configure this setting by entering the value (in hours) in the

400 Cleanup Age Limit for Non-Successful Jobs field. The value that you enter configures the Queue to delete the job during the cleanup interval, only if the age of the non-successful job is equal to or greater than that value. The method in which unsuccessful jobs are removed from the system is identical to the way successfully completed jobs are removed from the system. Note Jobs that are in an Unsuccessful and blocking correlation state stay in the history until they are successfully retried or canceled. The cleanup for non-successful jobs does not affect jobs in this state. The default value of this setting is 168 hours (7 days). Since job status information is important in helping to troubleshoot problems when a job has not completed successfully, we recommend not setting this value to less than the default setting. Bookkeeping Interval There are a number of Bookkeeping tasks that are executed by the Queuing System. For example, these include awakening jobs in a "sleeping" state, updating the heartbeat timestamp, checking whether the Queue Cleanup job needs to be executed, etc. The Bookkeeping Interval setting controls the time interval (in milliseconds) in which these tasks are run. The valid range is 500 (1/2 second) to (five minutes), with a default value of (ten seconds). Queue Timeout (in minutes) In a farm that contains multiple Application servers that are running the Project Server Application Service, if the Queue Service fails on one of the servers, jobs are automatically distributed among the remaining Application servers on which the Queue Service is online. A Queue Service is considered to have timed out if it cannot be accessed from the Queue health timer job for longer than the Queue Timeout value (in minutes). The valid range is 5 to 60 minutes, with a default value of 3 minutes. Note The Queue Timeout value cannot be less than four times the Bookkeeping Interval at any time. If this rule is violated, the Queue Timeout value will automatically be changed to four times the Bookkeeping value.

401 Add SharePoint task list data to Project Server /13/ min to read Edit Online Summary: You must ensure that all SharePoint Tasks list data is added to Project Server after importing it to Project Web App. Applies to: Project Server 2013 In SharePoint Server 2013, when a SharePoint Tasks list on a project site has been added to Project Web App, the task data is imported to Project Server If the SharePoint task list had been opened and saved in Project Professional 2013, a Project Professional MPP file will be associated with this task list, and it will be stored in the site's asset library. The MPP file contains additional data not stored in the task list that must be saved to Project Server 2013 manually. This includes data such as baselines, custom fields, and views. If you attempt to open the MPP file for the task list in Project Professional 2013, a warning message will appear that says: The SharePoint Task List for this project is now connected to Project Server, but additional steps are required to complete the connection. Clicking the Follow these steps button will open this TechNet article. If you add a SharePoint Tasks list to Project Server 2013 that has an associated MPP file, you must follow the procedure in this article to overwrite the project file in Project Server 2013 with the MPP file. This ensures that all of the task list data is imported into Project Server Note If the SharePoint Tasks list had never been opened and saved in Project Professional 2013, no action is required to add the additional task list data into Project Server If this is the case, an MPP file will not exist in the site's asset library. Overwriting the project file in Project Server Note Before you start this procedure, verify that Project Professional 2013 is closed on your desktop. To overwrite the project file in Project Server 1. Open the SharePoint site that contains your SharePoint Tasks list. 2. In the List ribbon, click Open with Project. This action opens the SharePoint Tasks list in Project Professional Important We recommend that you use the Open with Project button on the ribbon to open the task list in Project Professional This opens Project Professional 2013 with a configured connection to the project in Project Server If you open the task list in Project Professional 2013 by using the "most recently used" or the site asset library, you would need to manually configure the connection to Project Server In Project Professional 2013, click File, click Save As, and then click Save to Project Web App. In the Save to Project Web App dialog box, click Save. This overwrites the current file that is saved to Project Server. The Name field is automatically configured with the correct project name and is not editable, ensuring that

402 the correct file is overwritten on the server. Verify that the save job completes successfully, and then close Project Professional To verify whether the project file in Project Server 2013 has been overwritten successfully, go back to the SharePoint Tasks list on the site and click Open with Project. You will no longer see the warning message if the file has been overwritten successfully. This is because Project Professional 2013 will now be connecting to the project file in Project Server It will no longer have a connection to the MPP file in the site asset library. Important The MPP file will be completely disconnected from Project Server, but will still exist in the site asset library or might still be viewed in Project Professional 2013 as a recently accessed project. You can choose to delete or rename the MPP file to avoid confusion. See also Work with a task list Getting started with a project site

403 Technical reference for Project Server /13/ min to read Edit Online Summary: Information about technical reference content for Project Server. Articles with reference information for Project Server The following articles about Project Server are available to view online. CONTENT Windows PowerShell for Project Server 2016 cmdlet reference Global permissions in Project Server 2013 Category permissions in Project Server 2013 Default categories in Project Server 2013 Default group permissions in Project Server 2013 SharePoint Permissions Mode default permissions for Project Server 2013 SharePoint groups DESCRIPTION Microsoft PowerShell can be used with Project Server 2016 to perform both simple and complex administrative tasks. Project Server 2013 users are allowed access to features and functionality through global permissions. Project Server 2013 security categories have various permissions that allow or deny users the ability to do certain tasks with projects and resources. Project Server 2013 default security categories are associated to default security groups, providing a different set of category permissions to each group. Project Server 2013 default security groups have defined global permissions to allow you to access and use features and functionality. Learn about the corresponding Project Server permissions that SharePoint groups receive in SharePoint Permission Mode in Project Server 2013.

404 Windows PowerShell for Project Server 2016 cmdlet reference 12/13/ min to read Edit Online We are in the process of combining the Project Server 2013 and Project Server 2016 content into a single content set. We appreciate your patience while we reorganize things. See the Applies To tag at the top of each article to find out which version of Project Server an article applies to. Summary: A list of Windows PowerShell cmdlets for Project Server The following table describes the Microsoft PowerShell cmdlets available in Project Server CMDLET NAME Disable-ProjectServerLicense Disable-SPProjectActiveDirectoryEnterpriseResourcePoolSync Disable-SPProject Notification Disable-SPProjectEnterpriseProjectTaskSync Enable-ProjectServerLicense Enable-SPProjectActiveDirectoryEnterpriseResourcePoolSync Enable-SPProject Notification Enable-SPProjectEnterpriseProjectTaskSync Get-SPProjectEventServiceSettings Get-ProjectServerLicense Get-SPProjectDatabaseUsage Get-SPProjectEnterpriseProjectTaskSync Get-SPProjectIs NotificationEnabled Get-SPProjectOdataConfiguration DESCRIPTION Disables the Project Server functionality across the farm. Disables Timer Job execution of the Active Directory Enterprise Resource Pool synchronization. Turns off the Project Web App site level setting for notifications. Disables project task sync between Project Web App and project sites. Enables Project Server functionality in the farm. Enables Timer Job execution of the Active Directory Enterprise Resource Pool synchronization. Enables Project Server functionality in the farm. Enables project task sync between Project Web App and project sites. Returns the settings for the Microsoft Project Server Events Service Retrieves the status of the license for Project Server. Returns an approximate size, in megabytes (MB) of the Project Web App data used in the content database. Gets the status of project task sync between Project Web App and project sites. Returns the Project Web App site level setting for notifications. Returns the settings for how the OData service is configured for an instance of Project Web App.

405 CMDLET NAME Get-SPProjectPCSSettings Get-SPProjectPermissionMode Get-SPProjectQueueSettings Get-SPProjectWebInstance Invoke-SPProjectActiveDirectoryEnterpriseResourcePoolSync Invoke-SPProjectActiveDirectoryGroupSync Migrate-SPProjectDatabase Migrate-SPProjectResourcePlans New-SPProjectServiceApplication New-SPProjectServiceApplicationProxy Pause-SPProjectWebInstance Repair-SPProjectWebInstance DESCRIPTION Gets the settings for the Project Calculation Engine on the Project Server Returns the permission mode for a Project Web App instance. Returns a list of all Project Server 2016 Queue settings and their current values for the specified Project Server service application. Returns an instance of a Project Web App site. Triggers Active Directory Enterprise Resource Pool synchronization on the specified instance of Project Web App. Manually starts the synchronization job to synchronize Project Server 2016 group membership with the specified Active Directory groups. Copies the data from the Project Server 2013 database into the corresponding SharePoint Server 2016 content database containing the migrated site collection. Migrates the published resource plan assignment data to engagements. Run after data migration has been completed from Project Server 2013 to Project Server Creates a new Project Server service application. Creates a proxy for a Project Server service application. Switches the specified instance of Project Web App to readonly, preventing any changes from being made through the Project Server 2016 PSI or CSOM. Re-queues specific Project Server 2016 queue items that may have fallen out of the queue. Reset-SPProjectEventServiceSettings Resets the Microsoft Project Server Events Service 2016 settings to the default values. Reset-SPProjectPCSSettings Reset-SPProjectQueueSettings Resume-SPProjectWebInstance Set-SPProjectEventServiceSettings Set-SPProjectOdataConfiguration Resets the settings for the Project Calculation Engine on Project Server Resets all Project Server Queue settings to their default values for a specific Project Server service application. Switches the specified instance of Project Web App to readwrite mode, allowing users to change data again. Allows you to change the Microsoft Project Server Events Service 2016 TCP port settings. Sets the properties for how the OData service is configured for an instance of Project Web App.

406 CMDLET NAME Set-SPProjectPCSSettings Set-SPProjectPermissionMode Set-SPProjectQueueSettings Set-SPProjectServiceApplication Set-SPProjectUserSync Set-SPProjectUserSyncDisabledSyncThreshold Set-SPProjectUserSyncFullSyncThreshold Set-SPProjectUserSyncOffPeakSyncThreshold Sync-SPProjectPermissions Test-SPProjectServiceApplication Test-SPProjectWebInstance DESCRIPTION Sets the settings for the Project Calculation Engine on Project Server Changes the permission mode for a Project Web App instance. Running this cmdlet deletes all security settings and reverts to the default settings for the specified mode. Sets the value of one or multiple Project Server 2016 Queue settings for a specific Project Server service application. Sets the properties of a Project Server service application. Controls the behavior of WSS user sync. Defines the threshold over which a user sync job will not be executed but instead will be deleted. This threshold is the product of the number of projects multiplied by the number of users. Defines the threshold over which a delta user sync job will be executed as a complete user sync. This threshold is the product of the number of projects multiplied by the number of users. Defines the threshold over which a full user sync job will be executed during off peak hours instead of immediately. This threshold is the product of the number of projects multiplied by the number of users. Manually synchronizes permissions between a Project Web App instance and its associated project sites. Runs a serious of health checks against the Project Service Application. Runs a suite of tests on an existing Project Web Instance. See also Windows PowerShell for SharePoint 2013 reference

407 Global permissions in Project Server /13/ min to read Edit Online Summary: Project Server 2013 users are allowed access to features and functionality through global permissions. Important The Project Server 2013 environment must be in Project Permission Mode in order for you to view global permissions and other security settings. For more information about Project Permission Mode, see Plan user access in Project Server. The following is a list of global permissions for Project Server The columns in the table include the following: Description Describes what the permission enables you to do. Dependencies Lists any other permissions (global or category) or requirements necessary for the permission to function. New for Project Server 2013 Displays an symbol if the permission is new for Project Server Note For more information about how global permission work in the Project Server 2013 security model, see Plan groups, categories, and RBS in Project Server. PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Access Project Server Reporting Service Allows a user to access the OData web service for retrieving data from Project Server. Build Team On New Project Can be Delegate Allows a user to add resources to a project that has not been saved to Project Server. Grant this permission to project managers who want to use the Build Team feature in Project Professional 2013 to staff their projects before they save (and publish) them to Project Server. Specifies whether a user can be a delegate. User has to be granted the Assign Resources and View Enterprise Resource Data category permissions in order to see resources that are part of the Enterprise Resource Pool in the Build Team feature in Project Professional.

408 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Change Workflow Clean up Project Server database Contribute to Project Web App Edit Status Report Requests Log on Log on to Project Server from Project Professional Allows a user to change a project's Enterprise Project type. (Change Project Type). Allows a user to access the Delete Enterprise Objects page available through the Server Settings page in Project Web App. Grant this permission to users who have to delete timesheets, status reports responses, projects, resources, users, and user delegates from Project Server. Allows users to edit items within lists in Project Web App project sites. Allows a user to access the Request a status report link on the Project Web App Status Reports center and to view team reports. Grant this permission to any member of your organization who has to create status report requests and view team reports, usually project managers, resource managers, team leads, and members of your organization's PMO. Allows a user to connect to Project Server from Project Professional or to log on to Project Web App. Grant this permission to any user who is authorized to connect to Project Server from Project Professional or log on to Project Web App. Allows a user to load the Enterprise Global Template when he or she connects Project Professional to Project Server. Grant this permission to all users in your organization who will be using Project Professional to connect to Project Server.

409 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Active Directory Settings Manage Check-Ins Manage Cube Building Service Manage Drivers Manage Enterprise Calendars Manage Enterprise Custom Fields Manage Exchange Integration Allows users to modify any Active Directory Synchronization settings within the Project Web App Project Server Settings. If the user is denied this permission then they cannot modify settings for any of the following: Enterprise Resource Pool synchronization settings. Project Web App Security Groups synchronization settings. Choose an Active Directory Group to synchronize against a specific Security Group within the Add or Edit Group page. Allows a user to access the Forced Check-in Enterprise Objects page in Project Web App. This page lets users force check-in projects, resources, custom fields, calendars, lookup tables and resource plans. Allows a user to the set and modify the settings for OLAP cube creation. Allows a user to access the drivers.aspx page and manage business drivers for project portfolio analysis. Allows a user to create, modify, and delete Enterprise Calendars within Project Web App. Allows a user to modify the definitions of Enterprise Custom Fields and lookup table from Project Web App. Allows administrators to enable the synchronization of project tasks with Exchange Server.

410 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Gantt Chart and Grouping Formats Manage Lists in Project Web App Manage Notification and Reminders Manage My Delegates Manage My Resource Delegates Manage Personal Notifications Manage Portfolio Analyses Manage Prioritizations Allows a user to access the Gantt chart and grouping formats customization options in the Project Server Administration page for Project Web App views. Allows a user to create, modify, and delete lists within the Project Web App project site. This permission is used when you synchronize a user against the Project Web App project site. Allows a user to manage the Notification and Reminders settings. Allows users to see the "Manage Delegates" link and to set a delegate on the "Add/Modify Delegation" page. Allows users to set a user who requires a substitute on the Add/Modify Delegation page. Allows a user to access the Manage My Alerts and Reminders page in Project Web App. Grant this permission to any user that you want to be able to sign up for notifications and reminders related to tasks and status reports. Allows a user to create, read, update, and delete Portfolio analyses. Allows a user to create, read, update, and delete driver prioritizations.

411 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Project Web App Views Manage Queue Manage Resource Notifications Allows a user to access the Manage Views page in the Server Settings page in Project Web App. Users with permission to access this page are able to add, modify, or delete Project, Project Center, Resource Center, Assignment, or Portfolio Analyzer views, and they are able to modify Timesheet views. Grant this permission to project managers, resource managers, and members of your organization's PMO so that they can create project data views for users to access in Project Web App and Project Professional. It is important to remember that if your organization is allowing project managers to create custom fields at the project level, then each project may require its own unique view. The number of projects in this kind of environment may be too many for the IT administrator team. Offloading this work to the people in your organization that work at the project level on a day-to-day basis is one way to distribute the workload of managing views. Allows the user to read or set queue configuration settings and retry, cancel, and unblock jobs in the queue. Allows a user to access the "Alert me about my resources on tasks and status reports" link on the Project Web App home page. Grant this permission to any resource manager or project manager that you want to be able to sign up for notifications and reminders related to their resources' tasks and status reports.

412 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Rules Manage security Manage Server Events Allows a user to access the Rules page from the Approval Center in Project Web App and set rules on how update transactions will be automatically processed. Grant this permission to project managers, resource managers, or members of your organization's PMO so that they can define how they will automatically receive and accept changes to transactions by their resources. Allows a user to access the Manage security page in Project Web App to define security categories, security templates, and user authentication settings. Grant this permission to Project Server administrators or a very small and closely managed group of people. This page lets users change Project Server security settings, and create security categories and security templates. Changes to settings on this page, after you have begun using Project Server in your organization, should be carefully managed and (ideally) infrequent. Allows a user to register event handlers for specific Project Server server-side events. The Manager Server Events page requires the event handler to be registered by the server as defined in the Project Server SDK.

413 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Server Configuration Manage SharePoint Foundation Manage Time Reporting and Financial Periods Manage Time Tracking Allows a user to access the Project Web App Permissions page in Project Web App. Users with permission to access the Project Web App Permissions page can enable or disable enterprise features, manage organizational permissions, and create custom menus (both top-level and sidepane) in Project Web App. Grant this permission to Project Server administrators or a very small and closely managed group of people. Allows a user to create and delete project sites, configure automatic project site creation for newly published projects, configure permission synchronization settings, and update site path. Grant this permission to members of your organization who are administrators for Project Web App or administrators for the servers that are running SharePoint Server Allows a user to create and modify Timesheet and Fiscal period definitions. Allows a user to be forwarded timesheets for review. After reviewing the timesheet, the user must be granted the following permissions to accept and approve the timesheet: Accept Timesheet Approve Timesheet Users with this permission should be granted administrative privileges to all of the servers that are running Project Server 2013 and SharePoint Server 2013

414 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Manage Users and Groups Manage Workflow and Project Detail Pages New Project New Resource Allows a user to access the Manage Users and Groups page in the Server Settings page in Project Web App. Users with this permission will be able to add, modify, or delete Project Server users and manage Project Server security groups. Grant this permission to members of your organization who are Project Server administrators. Only a small group of people should have permission to access this set of pages. Allows a user to manage and view workflow and Project Detail Pages (PDPs). Allows a user to add a new project to Project Server using Project Professional, Project Web App, or the Project Server Interface (PSI). New functionality in Project Server 2013 for this permission: If you do not also have the Open Project permission, after you create a project, you are taken back to the Project Center. Allows a project manager to add new resources to the Enterprise Resource Pool using Project Professional, the Project Web App Resource Center, or the Project Server Interface (PSI). Grant this permission to any member of your organization who has to create new enterprise resources in Project Server. > [!NOTE]> If your organization is using the Active Directory synchronization feature, you may want to consider denying this permission to all non-it administrators in your organization.

415 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 New Task Assignment Open Project Template Allows users to access the Create a New Task and Add Yourself to a Task links from the Insert Row button found on the Tasks page of Project Web App. Grant this permission to any member of your organization who has to create new assignments on existing tasks in projects that have been published to Project Server. Users with this permission will also be able to use the Create a New Task link to create new tasks in Project Web App for any project to which the user has access. The list of available projects for a user to create new tasks is determined by the Create New Tasks or Assignment category permission. A user who has the New Task Assignment permission must also have access to the projects to which they want to assign themselves to a task. Allows a user to open an Enterprise Project Template from Project Server by using Project Professional. Grant this permission to all users in your organization who will use Project Professional to create and manage projects that are based on Enterprise Project Templates. User must be granted the New Project global permission in order to save the project to the Project Server database as an actual project.

416 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Reassign Task Save Enterprise Global Allows a user to delegate an assigned task to another (existing) user. Grant this permission to members of your organization who need the ability to delegate task assignments to other resources. For example, a large project may be run by a single project manager, but actually implemented by several teams, each with its own team lead. A project manager could assign the team leads in the project plan, and then the team leads could in turn delegate each task to individual members of the teams. This example creates an additional layer of task management within the larger organization, but it can also simplify resource allocation within projects themselves and make it easier for a project manager to manage large projects. Or, if you have a resource that is about to leave on a three-week vacation, and this resource had this permission, that person would be able to assign his or her tasks directly to other resources instead of having the project manager check out the project and reassign resources. Allows a user to check out, modify, and save the Enterprise Global Template to the Project Server database from Project Professional. This permission should only be granted to a small group of people in your organization; either project managers, members of your organization's PMO, or Project Server administrators.

417 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Save Project Template Save Unprotected Baseline Self-Assign Team Tasks Status Broker Permission Allows a user to create and save a project as an Enterprise Project Template from Project Professional to the Project Server database. Grant this permission to members of your organization who are tasked with creating Enterprise Project Templates. When a user saves a project to Project Server for the first time, the option to select Template (as opposed to Project) from the Type drop-down list in the Save to Project Server dialog box is enabled. Allows a user to save a non-protected baseline or clear a non-protected baseline associated with an enterprise project published to the Project Server database. Baselines are saved by using the Set Baseline functionality accessed from the Project Professional ribbon on the Project tab in the Schedule group. Click the Set Baseline button and then select Save Baseline or Clear Baseline. Unprotected Baselines are in the range of Baseline 6-10 inclusive. Resources can be members of a Team Assignment Pool. With this permission, it is possible for users to assign tasks, which have been assigned to their Team Assignment Pool, to themselves through the Team Tasks page in Project Web App. Allows API updates to occur for a user from places like Exchange Server. User needs to be granted the Assign Resources and View Enterprise Resource Data category permissions in addition to this permission if they are also responsible for adding Generic resources to the Enterprise Project Template. User needs to be granted the Save Project category permission.

418 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 View Approvals View Business Intelligence Link View OLAP Data View Project Center View Project Schedule Views View Project Timesheet Line Approvals View Resource Availability View Resource Center Allows a user to view the Approval Center. Allows a user to see the Business Intelligence link in Quick Launch. However, it has no effect on Report Center Security. Allows a user to read from the output for the OLAP cube. This permission is only checked when the OLAP cube is built. Allows users to access the Project Center from Project Web App or Project Professional. Allows a user to see the link in the Quick Launch. However, it has no effect on Report Center Security. Allows a user to approve timesheets on a line-by-line basis. Allows a user to access the View Resource Availability page to view resource allocation data in Project Web App. Grant this permission to users in your organization who need to view resource availability in Project Web App. Allows users to access the Resource Center from Project Web App or Project Professional and view resource allocation data. Grant this permission to users who need to view the Resource Center in Project Web App by clicking the Resources link in the toplevel navigation, or in Project Professional by selecting Resource Center on the Collaborate menu. Users have access to the Approval Center if they have either the Accept Timesheets or the View Approvals permission. User needs to be granted the View Project Summary in Project Center category permission. User needs to be granted the View Enterprise Resource Data category permission.

419 PERMISSION DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 View Resource Plan View Resource Timesheet View Task Center View Team Builder View Timesheets Allows a user to access the Resource Plan page within Project Web App. Allows users to view the timesheets, regardless of their state or ownership, for resources identified in the category selection criteria. This permission when denied prevents users from seeing the Task Center link on the Project Web App Quick Launch menu > [!NOTE]> This permission does not lock down access to the Task Center page. It is still possible for users to navigate to this page. Allows a user to use Build Team in Project Web App and Project Professional, as well as determine the list of available resources. Grant this permission to resource managers to allow them to use Build Team in Project Web App to add resources to projects that have been saved to the Project Server database. Project Managers can also use this permission to allow them to use Build Team in Project Professional to add resources to projects. When this permission is denied, it prevents users from seeing the Timesheet Center link on the Project Web App Quick Launch menu. > [!NOTE]> This permission does not lock down access to the Timesheet page. It is still possible for users to navigate to this page. Users must be granted the Accept Timesheet global permission to use this permission. User needs to be granted the Assign Resources category permission in addition to the View Team Builder global permission. The Assign Resources category permission determines the list of resources available in Build Team in both Project Professional and Project Web App. User needs to be granted the Build Team on Project category permission. The Build Team on Project permission determines with which projects Build Team can be used. This applies to using Build Team in both Project Professional and Project Web App. Project Server 2010 Global Permissions no longer available

420 The following are global permissions that were available in Project Server 2010 but are no longer available in Project Server 2013: About Project Server Approve Timesheets Close Tasks to Update Manage Site Services View Project View Edit Status Report Responses See also Category permissions in Project Server 2013 Default categories in Project Server 2013 Default group permissions in Project Server 2013 Plan user access in Project Server Plan groups, categories, and RBS in Project Server

421 Category permissions in Project Server /13/ min to read Edit Online Summary: Project Server 2013 security categories have various permissions that allow or deny users the ability to do certain tasks with projects and resources. Important The Project Server 2013 environment must be in Project Permission Mode in order to view category permissions and other security settings. For more information about Project Permission Mode, see Plan user access in Project Server. The following tables contain descriptions of all category permissions for Project Server The category permission descriptions are provided in two tables (Project and Resources), because category permissions apply to either projects or resources that are associated to a specific category. Note For information about different default security categories and their associated category permissions, see Default categories in Project Server For more information about security categories and how they are used in the Project Server 2013 security model, see Plan groups, categories, and RBS in Project Server. The table includes columns with the following information: Description Describes what the permission lets you do. Dependencies Lists any other permissions (global or category) or requirements to allow the permission to function. New for Project Server 2013 Displays an symbol if the permission is new for Project Server Category Permissions Project NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Accept Task Update Requests Allows a user to accept updates on projects without requiring that the user have the Save Project to Project Server permission.

422 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Build Team On Project Allows a user to add resources to a project that has already been saved to the Project Server database. Grant this permission to project managers who want to use the Build Team feature in Project Professional to staff their projects before they save (and publish) them to the Project Server database. Or grant this permission to resource managers who want to use the Build Team feature in the Project Center of Project Web App to add resources to a project that has already been saved to the Project Server database. User must have the View Enterprise Resource Data and Assign Resources category permissions in order to see resources that are part of the Enterprise Resource Pool in the Build Team feature in Project Professional and Project Web App. User must have permission (at the category level) to access the specific projects and resources that have to be accessed to build the project team or assign resources. Create Deliverable and Legacy Item Links Allows a user to create, modify, or delete links between Project tasks and items in the project site (documents, issues, deliverables, and risks). X Create New Task or Assignment Determines which projects are available when you are creating new tasks. Grant this permission to any group of projects that individual users will be able to create new tasks in by using the Create a new task page in Project Web App. User must be granted the New Task Assignment global permission in order to access the New task page in Project Web App.

423 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Delete Project Edit Project Summary Fields Manage Basic Project Security Manage Resource Plan Allows users of Project Professional to delete a project saved to the Project Server database from the Open from Microsoft Project Server dialog box in Project Professional. Grant this permission to members of your organization to enable them to more closely manage the projects he or she has saved to the Project Server database from Project Professional or by using the "Delete Enterprise Objects" link in Project Web App. Before letting users delete projects, you should consider how your organization will recover those projects, if you have to do so. Allows a user to edit only the enterprise project fields shown in the new project fields Web Part. If you do not have this permission, but have "Save Project to Project Server" you can still edit project-level fields/custom fields in the project field Web Part. Controls whether a specific Project Permission can be set on a single project through the new Project Permissions feature. Allows a user to edit a resource plan.

424 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Open Project Publish Project Save Project to Project Server Allows a user to open a project from the Project Server database in readonly mode by using Project Professional. Grant this permission to any member of your organization who has to use the Open from Microsoft Project Server dialog box in Project Professional or in the Project Center in Project Web App to open projects that have been saved to the Project Server database. If users are not assigned the Save Project to Project Server permission, then the project will only be open in read-only mode. Allows a user to Publish projects to the ProjectServices database by using Project Professional and Project Web App. Grant this permission to all members of your organization who will be publishing projects. Allows a user to save projects to the Project Server database by using Project Professional. Also gives Project Web App users the permission to save schedules and strategic impact data. Grant this permission to all members of your organization who will be saving projects from Project Professional to the Project Server database by using the Save to Project Server dialog box or through Server-side projects. User must be granted the Open Project category permission on any project that has to be checked out from the Project Server database. If the project has changed since opening, the user will be required to have the Save Project to Project Server permission on that project. If not, when a publish occurs, it will only publish the outdated version. User must be granted the New Project permission in order to create the project. User must be granted the Open Project category permission on any project that has to be checked out from the Project Server database.

425 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Save Protected Baseline View Project Schedule in Project Web App View Project Site Allows a user to save a protected baseline or clear a protected baseline associated with an enterprise project published to the Project Server database. Grant this permission to project managers who have to save baselines in their projects. Baselines are saved by using the Set Baseline functionality accessed from the Project Professional ribbon on the Project tab in the Schedule group. Click the Set Baseline button and then select Save Baseline or Clear Baseline. Protected Baselines are in the range of Baseline 0-5 inclusive. Only users who have Save Unprotected Baseline, Open Project and Save Project Category permissions are able to save Baselines in Baseline Allows a user to view project information for a specific project from the Project Center in Project Web App. Grant this permission to users who have to view project details in the Project Center. Allows users to view Risks, Issues, and Documents areas in Project Web App and Project Professional. Grant this permission to any user of Project Professional who has to select Project site, Documents, Issues, or Risks from the Info page in the Backstage or any user of Project Web App who has to access the Project site, Documents, Issues, or Risks top-level navigation links. User must be granted the Save Project to Project Server category permission.

426 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 View Project Summary in Project Center Allows a user to access a specific project in the Project Center from Project Web App. Grant this permission to any member of your organization who has to view projects summaries in the Project Center. Category Permissions Resource NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Adjust Timesheet Approve Timesheets Allows a Project Web App user to adjust a team member's submitted timesheet entries. Grant this permission to any member of your organization who requires the ability to adjust a resource's timesheet entry after that resource has submitted the entry. Allows a user to approve a team member's submitted timesheet entries. Grant this permission to any member of your organization who requires the ability to approve a resource's timesheet. User must have the View Resource Timesheet permission to use this permission. User must have the Approve Timesheets permission through a category which contains the resources which they want to approve timesheets on.

427 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Assign Resources Allows a user to assign or allocate a given resource to projects. This permission controls the list of available resources in Team Builder in both Project Web App and Project Professional. Grant this permission to all project managers and resource managers who have to assign, manage, or allocate resources. For example, if you want to add resource R to project P, then you must have permission to assign resource R (Assign Resources) plus permission to build the team on Project P (Build Team on Project). In addition, you must have access to the Team Builder page through either Project Web App or Project Professional (Assign Resources to Project Team). User must have the View Team Builder global permission in order to use the Build Team page in Project Web App or Project Professional. User must have the Build Team on Project category permission in order to assign a resource in an existing enterprise project. User must have the Build Team on New Project global permission in order to assign a resource in a new enterprise project.

428 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 Edit Enterprise Resource Data Manage Resource Delegates Allows a project manager to edit enterprise resource data by using Project Professional (checked-out Enterprise Resource Pool) or a resource manager to edit enterprise resources using Project Web App (Resource Center). Grant this permission to project managers and resource managers who have to make updates to resources that belong to the Enterprise Resource Pool. Resource managers with this permission are able to edit enterprise resource data in the Resource Center in Project Web App, and they can make updates to cost data, custom outline code data, custom field data, and other static information related to resources. Resource managers cannot add or delete resources from the Enterprise Resource Pool in Project Web App. Project managers can add or delete resources from the Enterprise Resource Pool in Project Professional if they have the New Resource global permission (to add resources) or the Clean Up Project Server Database global permission (to delete resources). These permissions are required in addition to the Edit Enterprise Resource Data category permission. > [!NOTE]> The Project Server Interface (PSI) can also be used to create or delete resources in the Enterprise Resource Pool and to edit enterprise resource data. Allows a user to see other users whom he or she manages and to set delegates for them. User must be granted the View Enterprise Resource Data category permission.

429 NAME DESCRIPTION DEPENDENCIES NEW FOR PROJECT SERVER 2013 View Enterprise Resource Data View Resource Assignments in Assignment Views Allows a user to view resources and resource data that is stored in the Enterprise Resource Pool. Grant this permission to any user who has to view resources and resource data that is stored in the Enterprise Resource Pool. Allows a user to view assignment details using assignment views in the Resource Center. Grant this permission to project managers and resource managers who have to view resource assignment details in the Resource Center from Project Professional or Project Web App. Note The "Create Object Link" permission is available in Project Server 2010, but is removed from Project Server See also Global permissions in Project Server 2013 Default categories in Project Server 2013 Default group permissions in Project Server 2013 Plan user access in Project Server Plan groups, categories, and RBS in Project Server

430 Default categories in Project Server /13/ min to read Edit Online Summary: Project Server 2013 default security categories are associated to default security groups, providing a different set of category permissions to each group. Important The Project Server 2013 environment must be in Project Permission Mode in order to view categories, groups, and other security settings. For more information about Project Permission Mode, see Plan user access in Project Server. Project Server 2013 creates five default security categories during installation. Each of the categories is associated to default security groups. Some security groups are associated to multiple categories. Each category provides the associated security group category permissions that allow it to perform certain tasks with projects and resources for that category. This article describes the default settings for each category for Project Server 2013, including the following: Category association to default security groups Lists the default categories that are associated with each default security group. Category permissions Lists each category permission that is allowed for each security group, as defined by the default category that is associated with that group. Category association to default security groups Specific default groups are already associated with each of the default categories. This means that users who are added to a specific default security group will automatically be allowed a specific set of permissions to work with the projects and resources that are associated with the category. Note For more information about the relationship between groups and categories, see Plan groups, categories, and RBS in Project Server. Categories associated with default security groups CATEGORY NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS My Direct Reports My Organizatio n My Projects My Resources

431 CATEGORY NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS My Tasks Category permissions The following table describes the default category permissions for each default group. For example, a user in the default Administrators group (who is associated to the My Organization category by default) has the permissions allowed in the Administrators column in the table. These category permissions only apply to all projects, resources, and views selected for the My Organization category. However, a user in the default Project Managers group (who is associated to the My Organization and My Projects categories) has a different set of category permissions for the objects in the My Organization category. This allows you to conveniently set a more or less restrictive set of permissions for different types of users to a group of projects, resources, and views. Note For more information about category permissions, see Category permissions in Project Server For more information about how categories relate to groups, see Plan groups, categories, and RBS in Project Server. Use the following legend for the table below. My Org = My Organization My Dir = My Direct Reports My Proj = My Projects My Res = My Resources My Tsks = My Tasks Category permissions for default categories PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Accept Task Update Requests My Org My Proj Adjust Timesheet My Org My Org Approve Timesheets Assign Resource Build Team On Project My Org My Org My Org, My Res My Org My Org My Org My Res My Org My Proj My Org

432 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Create Deliverable and Legacy Item Links My Org My Org My Org My Proj My Org, My Proj, My Res My Proj My Tsks Create New Task or Assignment Delete Project Edit Enterprise Resource Data My Org My Proj My Proj My Proj My Tsks My Org My Org My Proj My Org My Org My Res Edit Project Summary Fields Manage Basic Project Security My Org My Org My Proj My Proj Manage Resource Delegates My Org My Res Manage Resource Plan Open Project My Org My Org My Res My Org My Org My Proj Publish Project Save Project to Project Server Save Protected Baseline My Org My Org My Org My Proj My Proj My Proj View Enterprise Resource Data My Org My Org My Org My Org, My Proj My Res

433 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS View Project Schedule in Project Web App View Project Site View Project Summary in Project Center View Resource Assignment s in Assignment Views My Or My Org My Org My Proj My Proj My Tsks My Org My Org My Org My Proj My Proj My Proj My Tsks My Org My Org My Org My Proj My Proj My Proj My Tsks My Org My Org My Org My Proj My Res My Proj My Tsks See also Global permissions in Project Server 2013 Category permissions in Project Server 2013 Default group permissions in Project Server 2013 Plan user access in Project Server Plan groups, categories, and RBS in Project Server

434 Default group permissions in Project Server /13/ min to read Edit Online Summary: Project Server 2013 default security groups have defined global permissions to allow you to access and use features and functionality. Important The Project Server 2013 environment must be in Project Permission Mode in order to view categories, groups, and other security settings. For more information about Project Permission Mode, see Plan user access in Project Server. This article describes the global permissions that are given to the default templates and security groups in Project Server Project Server 2013 creates seven default groups during installation: Administrators Portfolio Managers Portfolio Viewers Project Managers Resource Managers Team Leads Team Members Each group is given a default set of global permissions. Templates are also included to allow these default permissions to be assigned to new groups created by the administrator. After you use the template to create a new group, you can then choose to customize the new group to better suit your users by editing the permission for the group. Global permissions differ from category permissions in that they apply to functionality that the user is allowed to do throughout Project Server In order to work with specific projects or resources, users must have access to them through a category to which the project or resource is added. The users are only allowed to do tasks with these specific projects and resources through the category permissions defined in the category. For more detailed information about groups and categories, see Plan groups, categories, and RBS in Project Server. Note For information about the default categories that are associated to default security groups, as well their corresponding category permissions, see Default categories in Project Server Security group default global permissions The following table contains a list of the default global permissions for each of the default security groups. Default global permissions for Project Server security groups

435 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Access Project Server Reporting Service Build Team On New Project Can Be Delegate Change Workflow Clean Up Project Server Database Contribute to Project Web App Edit Status Report Requests Log On Log on to Project Server from Project Professional Manage Active Directory Settings Manage Check-Ins Manage Cube Building Service Manage Drivers

436 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Enterprise Calendars Manage Enterprise Custom Fields Manage Exchange Integration Manage Gantt Chart and Grouping Formats Manage Lists in Project Web App Manage My Delegates Manage My Resource Delegates Manage Notification and Reminders Manage Personal Notification s Manage Portfolio Analyses Manage Prioritizatio ns Manage Project Server Backup

437 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Project Server Restore Manage Project Web App Views Manage Queue Manage Resource Notification s Manage Rules Manage Security Manage Server Configurati on Manage Server Events Manage SharePoint Foundation Manage Time Reporting and Financial Periods Manage Time Tracking Manage Users and Groups

438 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Workflow Project Detail Pages New Project New Resource New Task Assignment Open Project Template Reassign Task Save Enterprise Global Save Project Template Save Unprotecte d Baseline Self-assign Team Tasks Status Broker Permission View Approvals View Business Intelligence Link View OLAP Data View Project Center

439 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS View Project Schedule Views View Project Timesheet Line Approvals View Resource Availability View Resource Center View Resource Plan View Resource Timesheet View Task Center View Team Builder View Timesheets See also Global permissions in Project Server 2013 Category permissions in Project Server 2013 Default categories in Project Server 2013 Plan user access in Project Server Plan groups, categories, and RBS in Project Server

440 SharePoint Permissions Mode default permissions for Project Server 2013 SharePoint groups 12/13/ min to read Edit Online Summary: Learn about the corresponding Project Server permissions that SharePoint groups receive in SharePoint Permission Mode in Project Server SharePoint Permission Mode creates SharePoint groups that directly correspond to the default security groups found in Project Permission Mode. These default security groups include the following: Administrator Portfolio Managers Portfolio Viewers Project Managers Resource Managers Team Leads Team Members Users in these SharePoint groups have the same global and category permissions that are assigned to them in Project Permission Mode in Project Server 2013 For example, the Project Managers SharePoint group in SharePoint Permission Mode receive all allowed global and category permissions that the Project Managers default security group has in Project Server 2013 in Project Permission Mode. Important In SharePoint Permission Mode, you cannot edit the default permissions assigned to any of these SharePoint groups. Also, you cannot create additional custom groups, categories, Resource Breakdown Structure (RBS) nodes, or edit the default permissions assigned to any of these objects. If you need more management of your user permissions in Project Server 2013, you can change to Project Permission Mode. For more information about the differences between the two security modes available to you in Project Server 2013, see Plan user access in Project Server. Note For more information about SharePoint groups in SharePoint Permission Mode for Project Server 2013, see Plan SharePoint groups in Project Server. Permissions for SharePoint groups in Project Server 2013 This section provides a list of permissions allowed for each SharePoint group in SharePoint Permission Mode in Project Server Note that there are two different types of permissions for Project Server 2013 users. Global permissions: Allow users to use and access sites and features in Project Server Category permissions: Allows users to do tasks with project, resources, and views in Project Server 2013.

441 Note For descriptions of Project Server 2013 global and category permissions, see the following articles:> Global permissions in Project Server 2013> Category permissions in Project Server 2013 Global permissions for SharePoint groups in SharePoint Permission Mode PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Access Project Server Reporting Service Build Team On New Project Can Be Delegate Change Workflow Clean Up Project Server Database Contribute to Project Web App Edit Status Report Requests Log On Log on to Project Server from Project Professional Manage Active Directory Settings Manage Check-Ins

442 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Cube Building Service Manage Drivers Manage Enterprise Calendars Manage Enterprise Custom Fields Manage Exchange Integration Manage Gantt Chart and Grouping Formats Manage Lists in Project Web App Manage My Delegates Manage My Resource Delegates Manage Notification and Reminders Manage Personal Notification s Manage Portfolio Analyses

443 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Prioritizatio ns Manage Project Server Backup Manage Project Server Restore Manage Project Web App Views Manage Queue Manage Resource Notification s Manage Rules Manage Security Manage Server Configurati on Manage Server Events Manage SharePoint Foundation Manage Time Reporting and Financial Periods Manage Time Tracking

444 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Manage Users and Groups Manage Workflow Project Detail Pages New Project New Resource New Task Assignment Open Project Template Reassign Task Save Enterprise Global Save Project Template Save Unprotecte d Baseline Self-assign Team Tasks Status Broker Permission View Approvals View Business Intelligence Link View OLAP Data

445 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS View Project Center View Project Schedule Views View Project Timesheet Line Approvals View Resource Availability View Resource Center View Resource Plan View Resource Timesheet View Task Center View Team Builder View Timesheets Category permissions for SharePoint groups in SharePoint Permission Mode PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Accept Task Update Requests Adjust Timesheet Approve Timesheets

446 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS Assign Resource Build Team On Project Create Deliverable and Legacy Item Links Create New Task or Assignment Delete Project Edit Enterprise Resource Data Edit Project Summary Fields Manage Basic Project Security Manage Resource Delegates Manage Resource Plan Open Project Publish Project Save Project to Project Server Save Protected Baseline

447 PERMISSION NAME ADMINISTR ATORS PORTFOLIO MANAGERS PORTFOLIO VIEWERS PROJECT MANAGERS RESOURCE MANAGERS TEAM LEADS TEAM MEMBERS View Enterprise Resource Data View Project Schedule in Project Web App View Project Site View Project Summary in Project Center View Resource Assignment s in Assignment Views

448 Project Server 2016 knowledge articles for Systems Center Operations Manager 12/18/ min to read Edit Online Summary: Learn how to resolve alerts about Project Server in the SharePoint Server 2013 management pack for Systems Center Operations Manager (SCOM). The articles in this section are knowledge articles for Project Server 2013 that appear in the SharePoint Server 2016 management pack (MP). Typically, you would see these articles after clicking a link in an alert in the Operations Manager console. You can use these articles to help you troubleshoot and resolve problems in Project Server New SCOM alerts in Project Server 2013: Project WFE to application server connection failed (SharePoint 2013 monitoring rule) Project WFE to application server connection failed Alerts for Project Server 2013 and Project Server 2010: Project Active Directory Connection Failed Project Active Directory Exception Occurred During Synchronization Project Active Directory Nested Foreign Security Principal Could Not Be Resolved Project Active Directory Nested Object Could Not Be Resolved Project Active Directory PWA Group Could Not Be Resolved Project Active Directory Top Level Group Has No Members Project Creating Report Center Web Failed Project Cube Build Service Analysis Services Server Connection Failure Project Cube Build Service Analysis Services Server Lock Time Out Project Cube Build Service Attempt To Overwrite Failed Project Cube Build Service Decision Support Object Is Not Installed Project Cube Build Service OLAP Processing Failure Project Failure Creating a Project Workspace Project General Data Access Layer Error Connecting To Database Project General Data Access Layer Error While Getting Connection Strings Project Notification Delivery Failed Project Notification XSLT Transformation Error Project Queue General Percentage SQL Retries Per Day Project Queue General Percentage SQL Retries Per Hour Project Queue Jobs Average Wait Time Per Day

449 Project Queue Jobs Percentage Jobs Failed Per Day Project Queue Jobs Percentage Jobs Failed Per Hour Project Queue System Restarting Due to Unexpected Error Project Reporting Server Side Event Has Failed Project Server Side Event Handler Could Not Be Found Project Server Event Service Could Not Be Found Project SQL User View Refresh Message Was Not Queued Project User View Was Truncated Project Windows SharePoint Services Format Error Project Winproj Average Time Taken For Project Open Project Winproj Percentage Of Incremental Save To Full Save Project Workspace User Synchronization Failed Project WFE to application server connection failed (SharePoint 2013 monitoring rule) Alert Name:Project WFE to application server connection failed Summary: This alert occurs when a Project Server front-end server cannot connect to a back-end server. Requests are no longer transferred from the front-end to the back-end. Cause Potential root causes include: Hardware issues Networking issues Permissions issues Resolution Check standard connectivity on the faulty computers: 1. Ensure there are no hardware failures on any computer that reported the error. 2. Perform basic network connectivity checks between the front-end and back-end computers. 3. Check Project service accounts credentials and permissions. Project WFE to application server connection failed Alert Name:Project WFE to application server connection failed Summary: This alert occurs when a Project Server front-end server cannot connect to a back-end server. Requests are no longer transferred from the front-end to the back-end. Cause Potential root causes include: Hardware issues

450 Networking issues Permissions issues Resolution Check standard connectivity on the faulty computers: 1. Ensure there are no hardware failures on any computer that reported the error. 2. Perform basic network connectivity checks between the front-end and back-end computers. 3. Check Project service accounts credentials and permissions. See also Operations for Project Server 2016 Plan for monitoring in SharePoint 2013 Monitor health in SharePoint 2013 System Center Operations Manager knowledge articles (SharePoint 2016 Preview)

451 Scenarios and solutions for Project Server 12/13/ min to read Edit Online Summary Learn about using Project Server to create solutions for project management. The articles in this section help you apply and integrate Project Server and Project Web App to solve your project management needs. CONTENT Transitioning projects from SharePoint to Project Server 2013 Using workflow for demand management in Project Server Portfolio analysis overview DESCRIPTION Gradually grow your projects from a SharePoint task list to a full Project Web App project. Learn to use workflows in Project Web App. Learn to do a portfolio analysis in Project Web App.

452 Transitioning projects from SharePoint to Project Server /13/ min to read Edit Online Summary: Learn how to increase the Project Web App functionality level for a project as project management needs become more complex. Applies to: Project Server 2013 SharePoint Server and Project Server 2013 provide the ability to incrementally increase the project management capabilities and features for a project as the project grows and becomes more complex. Projects can start as a simple SharePoint task list and gradually grow into a full enterprise project using all the features available in Project Server. Important This scenario applies only to Project Server In this article: Scenario overview Before you begin Create SharePoint task list projects Enable the Project Web App site collection features Add a Project Center web part Import a project Activate enterprise project features for a project Add a Project Web App site Scenario overview This scenario walks through the progression of steps that you can take to transition a SharePoint task list project to a full enterprise project in Project Web App for Project Server. These are steps that you would normally take over some period of time as your project management requirements increase for a particular project. The purpose of this article is to show what those steps are and the order in which they are done. The basic progression is: 1. Create a site and add a SharePoint task list to that site. 2. Update the task list project using Project Server if needed. 3. Enable the Project Web App site collection features for the site collection where your task list project is located. 4. Add a Project Center web part and import the task list project into the Project Web App database. 5. Activate the enterprise project features for the task list project.

453 6. Add a Project Web App site to the site collection. Each of the above steps adds new functionality that you can use to manage the project. When planning your project sites, it's important to plan your site collections carefully if you want to keep related projects together.you can create multiple site collections, each with their own projects, but each site collection is distinct and projects cannot be shared between site collections. When you deploy a Project Web App site to a given site collection, it can only be used to manage projects in that site collection. Before you begin Before starting, read the following information about permissions and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings. For example: For the procedures in this article that use the SharePoint Central Administration website, you must use an account that is a farm administrator or a Project Server service application administrator. For the procedure in this article that use Project Server, you must be logged into a computer running a Windows client operating system such as Windows 7 and you must have Project Server installed. Create SharePoint task list projects You can create task lists on team sites or project sites using SharePoint Server without the need of having Project Server 2016 installed on the farm. You can accomplish many basic project management tasks by using a SharePoint task list, including editing these projects in Project Server. While you can create a task list on a team or project site in any site collection, for easiest long term management, we recommend creating a new site collection to use for project sites. When planning your project sites, it's important to plan your site collections carefully. You can create multiple site collections, each with their own projects, but each site collection is distinct and projects cannot be shared between site collections. When you deploy a Project Web App site to a given site collection, it can only be used to manage projects in that site collection. Use the following procedure to create a site collection. To create a site collection 1. On the SharePoint Central Administration website, under Application Management, click Create site collections. 2. In the Web Application section, choose the web application where you want to create the site collection. 3. In the Title text box, type a title for the site. 4. In the Web Site Address section, type the URL where you want the site to be created. 5. In the Template Selection section, choose Team Site. 6. In the Primary Site Collection Administrator section, type the name of the primary site collection administrator. 7. Optionally, specify a secondary site collection administrator and a quota template. 8. Click OK. Once the site collection has been created, you must grant access to it for your users. Users will need Edit access in order to work with SharePoint task list projects. Use the following procedure to grant access to your users.

454 To grant access to a site collection 1. Navigate to the root of the site collection that you created. 2. In the ribbon, click Share. 3. Type the names of the users or groups to whom you want to grant access, and then click Share. While you can create a project site directly on the root of the site collection, we recommend creating a subsite for each project that you plan to manage. Use the following procedure to create a subsite. To create a subsite 1. Navigate to the root of the site collection that you created. 2. On the Settings menu, click Site Settings. 3. On the Site Settings page, under Site Administration, click Sites and workspaces. 4. On the Sites and Workspaces page, click Create. 5. In the Title text box, type a title for the site. 6. In the Web Site Address section, type the URL where you want the site to be created. 7. In the Template Selection section, choose Team Site. 8. Click Create. Once you have created a subsite, you can add the Tasks and Calendar apps to it. This essentially converts a team site to a project site. Note You can choose the Project Site template and the Tasks and Calendar apps will be included. In this case, we chose Team Site to illustrate how to add the Tasks and Calendar apps to an existing team site. Use the following procedure to add the Tasks and Calendar apps to the site. To add the Tasks and Calendar apps to a site 1. Navigate to the subsite that you created. 2. Click the Working on a deadline? tile. 3. On the Working on a deadline? dialog box, click Add Them. Once you have added the Tasks and Calendar apps, you can create a SharePoint list project. Use the following procedure to create a project. To create a SharePoint list project 1. On the subsite, click Edit the task list. 2. Add one or more tasks to the task list and assign people and due dates to them. For greater versatility in managing your project, you can open it in Project Server directly from the SharePoint list. Use the following procedure to open the project in Project Professional. You must do this on a client computer that is running Project Professional. To open a task list in Project Professional

455 1. On the subsite, in the left pane, click Tasks. 2. In the ribbon, on the List tab, click Open with Project. 3. Add one or more tasks to the task list and assign people and due dates to them. 4. Click File, and then click Save. 5. Close Project Professional. 6. Refresh the Tasks page to see your changes. You can continue to use the SharePoint task list and Project Professional to manage your project for as long as that meets your needs. Enable the Project Web App site collection features Enabling the Project Web App site collection features adds additional functionality to the site collection, including: The ability to import SharePoint task list projects into Project Web App. The ability to create reports using data from multiple imported projects. New SharePoint security groups specific to Project Web App to help you manage access to your projects. Enabling the Project Web App site collection features requires that you have Project Server 2016 deployed on the farm. Enabling the Project Web App site collection features consists of two steps: Create a Project Web App database Enable the Project Web App site collection features A Project Web App database is created using the New-SPProjectDatabase Microsoft PowerShell cmdlet. In order for the new database to be properly associated with the site collection where you want enable the Project Web App site collection features, you must use the Tag parameter to associate a unique string with this database. That string will be used later when you enable the site collection features. Run the following cmdlet to create a new Project Web App database. New-SPProjectDatabase -Name DatabaseName -ServiceApplication "ServiceApplicationName" -DatabaseServer SQLServerInstance -Tag String For example: New-SPProjectDatabase -Name ProjectWebApp1 -ServiceApplication "Project Service Application" -DatabaseServer Contoso-SQL -Tag "ProjectWebApp1DB" Note You can find the name of the Project Server service application in Central Administration by clicking Manage service applications under Application Management. Once you have created the new Project Web App database, the next step is to enable the Project Web App site collection features. Doing so will associate the database that you just created with the site collection. The Project Web App site collection features are enabled by using the Enable-SPFeature PowerShell cmdlet. Prior to running this cmdlet, you must set the PWA_TAG parameter of the site collection to match the Tag parameter

456 that you set when you created the database. Use the following PowerShell script to set the PWA_TAG parameter and then enable the Project Web App site collection features. $web=get-spweb SiteCollectionURL $web.properties["pwa_tag"]="string" $web.properties.update() Enable-SPFeature pwasite -URL SiteCollectionURL For example: $web=get-spweb $web.properties["pwa_tag"]="projectwebapp1db" $web.properties.update() Enable-SPFeature pwasite -URL After the Project Web App site collection features have been activated for the site collection, the next step depends on the needs of your organization. You can do one of the following: Add a Project Center web part to the site collection - this allows you to import SharePoint list projects into SharePoint list projects into Project Web App. Adding the web part can be done by anyone with Design permissions on the site. If you do not yet require the full functionality of a Project Web App site, this is an easy way to enable importing projects without the need to involve a system administrator. Add a Project Web App site to the site collection - this gives you full Project Web App functionality. If you choose this option, there is no need to add a separate Project Center web part, as one is included as part of the Project Web App site. In the next section, we will walk through the more gradual approach of adding the Project Center web part first. In your environment, consider which approach is best for you. Add a Project Center web part The Project Center web part provides the necessary functionality for importing SharePoint list projects into Project Web App. This web part can be added to any site in the site collection. In this example, we assume that you are adding it to the root of the site collection. Use the following procedure to add a Project Center web part. Note You must have Design permissions on the site to perform this procedure. To add a Project Center web part 1. Navigate to the root of the site collection that you created. 2. In the ribbon, on the Page tab, click Edit. 3. Place your cursor below the Documents web part (or wherever you want to add the Project Center web part). 4. In the ribbon, on the Insert tab, click Web Part. 5. In the Categories list, click Project Web App. 6. In the Parts list, click Project Center.

457 7. Click Add. 8. Click the Project Center web part, and then in the ribbon, on the Web Part tab, click Web Part Properties. 9. In the web part properties pane, expand Project Web App. 10. Type the URL of the root of the site collection that you created. 11. Click OK. 12. In the ribbon, on the Page tab, click Save. To view projects in the Project Center web part, you must be a member of one of the Project Web App security groups on the site collection. Use the following procedure to add one or more users to a Project Web App security group. To add a user to a Project Web App security group 1. Navigate to the root of the site collection that you created. 2. On the Settings menu, choose Site Settings. 3. On the Site Settings page, under Users and Permissions, choose People and groups. 4. On the People and Groups page, in the left pane, click More Click the Project Web App group to which you want to add users. Note Team Members for Project Web App is sufficient to see projects in the Project Center web part. 6. Click New. 7. Type the users that you want to add to the group, and then choose Share. Import a project You must be a member of the Project Managers for Project Web App or Administrators for Project Web App security groups in the site collection in order to import a project. To import a project 1. Navigate to the root of the site collection that you created. 2. On the Projects tab, click Add SharePoint Sites. 3. On the Add SharePoint Sites to Project Web App dialog box, select the check box for the projects that you want to import, and then click Add. The project import process is processed by the Project Server queue. You can check the queue to confirm that the import process has completed successfully. Use the following procedure to check the status of the import job. Note You must be a farm administrator or Project Server service application administrator to perform this task. To check the status of the project import queue job 1. In Central Administration, under Application Management, choose Manage service applications.

458 2. Choose the Project Server service application. 3. Hover over the instance of Project Web App where you want to check the queue, click the arrow that appears, and then click Manage. 4. Under Queue and Database Administration, click Manage Queue Jobs. 5. Expand Job Completion States and add all job states to the Selected Job States box. 6. In the Job Grid, click Refresh. 7. Check the Job Type column for Project Import Task List and then check the Job State column for the state of that job. The Job State will be Success when the project import task has completed successfully. After a project has been imported, you must be a member of the Project Managers for Project Web App security group in the site collection to open a project in Project Professional. If you edited the task list in Project Professional prior to importing it, then you must reconcile the project and enterprise resources using Project Professional after the import has completed. Note If resource reconciliation is required, you will see the following warning when you open the project in Project Professional: The SharePoint List for this project is now connected to Project Web App, but additional steps are required to complete the connection. Use the following procedure to reconcile project and enterprise resources. Note You must be a member of the Administrators for Project Web App security group in the site collection in order to perform this task. To reconcile project and enterprise resources 1. Navigate to the subsite. 2. In the left navigation, click Tasks. 3. In the ribbon, on the List tab, click Open with Project. 4. In Project Professional, on the Resource tab, click Add Resources, and then click Build Team from Enterprise. 5. On the Build Team dialog box: 6. For each enterprise resource, select the resource in the Enterprise Resource list, select the resource with the same name in the Project Resources list, and then click Replace. Note Project resources for which there is no enterprise resource equivalent will be imported in the next step. 7. Click OK. 8. On the Resource tab, click Add Resources, and then click Import Resources to Enterprise. 9. In the left pane, click Continue to Step 2.

459 Any resources available for import will appear in the center pane. 10. Click Save and Finish. 11. On the File tab, click Save As. 12. Under Project Web App, click Save. 13. On the Save to Project Web App dialog box, click Save. 14. Close Project Professional. When prompted to check the project in, click Yes. Activate enterprise project features for a project As your project management needs grow for a project, you can convert an imported SharePoint task list project into an enterprise project. Doing so provides additional features, such as timesheets and workflow. Once the project becomes an enterprise project, the SharePoint task list becomes read-only and the project must be edited in Project Professional or Project Web App. Use the following procedure to activate the enterprise features for the project that you imported. Note You must be a member of the Administrators for Project Web App security group in the site collection in order to perform this task. To activate enterprise features for an imported project 1. Navigate to the site collection where the project is located. 2. On the Settings menu, choose Project Web App Settings. 3. On the Project Server Settings page, in the Operational Policies section, click Connected SharePoint Sites. 4. On the Connected SharePoint Sites page, in the Enterprise Project Features column, click Activate for the project where you want to activate the enterprise features. Add a Project Web App site You can add a Project Web App site to the site collection where you have created the SharePoint list projects. Doing so will allow you to take full advantage of Project Server 2013 and Project Web App functionality for the projects in that site collection. To create a Project Web App site in an existing site collection, you run the New-SPweb Microsoft PowerShell cmdlet to create the site and then run the Upgrade-SPProjectWebInstance to perform post-provisioning actions, including creating a Business Intelligence Center. Run the following script to create the Project Web App site. New-SPweb -URL SiteCollectionURL/PWASiteName -Template pwa#0 Upgrade-SPProjectWebInstance -Identity SiteCollectionURL -Confirm:$False For example: New-SPweb -URL -Template pwa#0 Upgrade-SPProjectWebInstance -Identity -Confirm:$False

460 After you have created the Project Web App site and run Upgrade-SPProjectWebInstance, you must run iisreset on each application server in the farm. To run iisreset, open a command window, and type: iisreset /noforce The Project Web App site is now available at the URL that you specified. See also Create a PWA site in an existing site collection Enable the Project Web App site collection features in Project Server 2016 Add SharePoint task list data to Project Server 2013

461 Using workflow for demand management in Project Server 12/13/ min to read Edit Online Summary: Learn about phases, stages, enterprise project types, and workflows in Project Server 2013 and Project Server 2016 demand management. Applies to: Project Server 2016, Project Server 2013 This article describes how demand management is implemented in Project Server. For additional details, see Hitchhiker's Guide to Demand Management in Project Server 2013 (white paper). You can use the demand management tools in Project Web App to capture all project ideas in one place, and then guide them through a decision-making process catered to your business's needs. Using these tools can help your users make decisions about which proposals to approve, and track progress on a project until the work is completed. Demand management in Project Server uses: Project detail pages - Project Web App pages where users can view and update project information. Stages - sets of project detail pages specific to one area of the project lifecycle. Phases - a way to organize multiple stages. Workflows - a way to enforce your business processes as projects move through the various phases and stages. Enterprise project types - a way to bring phases, stages, and project detail pages together with a workflow into a standardized way of doing a project. We'll go over each of these in the sections that follow. Project detail pages Project Web App users view or update project data on project detail pages. You can customize a project detail page by choosing web parts that use the fields you want displayed. In demand management, project detail pages are displayed to the user at various stages of a project whenever you need to gather information from or display information to a user. Stages A stage includes one or more project detail pages, grouped to gather information about a project. This information can be used or updated by a workflow. In Project Web App, you can define which project detail pages are displayed in a given stage, which fields are required and which are read/write or read-only, and which phase (we'll talk about phases in the next section) the stage is part of. For each stage of a project, we recommend that you define what actions need to take place and what information needs to be gathered based on your business requirements for the project. This information will help you define the list of fields that you need to display in the project detail pages and what actions you need the workflow to take. The following steps list the general procedure:

462 1. Define what needs to happen with the project in each stage 2. Define the required information that you want to capture using project detail pages 3. Define the state of the fields in each stage (Required, read/write, or read-only) Phases A demand management phase is used to organize multiple stages that make up a common set of activities in the project life cycle. Examples of phases are project creation, project selection, and project management (represented in the default Project Web App phases as Create, Select, and Manage). The phases themselves are just a way of organizing your stages and do not determine the order in which the stages are executed. (The order of the stages is determined by the associated workflow.) Workflows Workflows enforce your business processes and provide a structured way for projects to move through phases and stages. You can set up a workflow to do a variety of actions based on the user input for each stage, including sending s, assigning tasks, and waiting for specific project actions. For example, you might have an "Initial Proposal" stage where you include a project detail page with a custom field for project cost. You could configure the workflow to automatically accept or reject the project based on whether the project cost exceeds a certain limit. The image below shows the five phases of demand management that are included in Project Web App and how they fit together. Within each phase are example stages such as "Propose idea" and "Initial review." Each stage can have one or more associated project detail pages. The entire collection of stages represents a single workflow that can be associated with an enterprise project type. There are four general steps to perform to create your workflow in Project Web App: 1. Design the workflow based on your business requirements. 2. Create the needed custom fields, project detail pages, phases, and stages in Project Web App. 3. Create the workflow in SharePoint Designer 2013 and deploy it to Project Web App. 4. Create an enterprise project type that uses the workflow. Enterprise project types An enterprise project type brings together all the elements of demand management by combining a single workflow with its phases and stages with department and project site template definitions. Normally, enterprise project types are aligned with individual departments, for example, marketing projects, IT projects, or HR projects. Using enterprise project types helps to categorize projects within the same organization that have a similar project

463 life cycle. For a user, the enterprise project types appear in a drop-down list when the user clicks New Project in the Project Center.

464 Best practices for creating phases and stages 12/13/ min to read Edit Online Summary: Use these naming conventions for work management phases and stages to make administration easier. Applies to: Project Server 2016, Project Server 2013 You can name your demand management phases and stages any way you'd like, but using the following guidelines can save you time as an administrator and make things easier to find. For each phase or stage that you create in Project Web App, we recommend using specific naming conventions. We also recommend that you create unique phases and stages for each enterprise project type. These conventions can provide easier maintenance as you expand your usage of demand management features. For phases: Create unique phases for each workflow and prefix the phase with an acronym that categorizes the workflow (for example, IT). Add a number after the acronym so that phases appear in chronological order. The following table shows an example of how you might name the phases of IT projects. PHASE NAME IT-1 Create IT-2 Select IT-3 Plan IT-4 Manage IT-5 Finish DESCRIPTION Create phase for IT projects. Select phase for IT projects. Plan phase for IT projects. Manage phase for IT projects. Finish phase for IT projects. For stages: Add the appropriate acronym and a number before the title of the stage to cause the stages to appear chronologically. Create unique stages for each workflow. This allows you to make changes to a stage in one workflow without affecting other workflows. The following table shows an example of how you might name the stages of IT projects. STAGE NAME IT-1 Propose idea IT-2 Initial review IT-3 Complete request DESCRIPTION Propose idea stage for IT projects. Initial review stage for IT projects. Complete request stage for IT projects.

465 STAGE NAME IT-4 Request review IT-5 Portfolio selection DESCRIPTION Request review stage for IT projects. Portfolio selection stage for IT projects.

466 Create a sample Project Web App workflow 12/13/ min to read Edit Online Summary: Create sample workflow components to use in learning about Project Web App workflows. Applies to: Project Server 2016, Project Server 2013 In this article, we're going to set up some basic workflow infrastructure that we can use to demonstrate workflow functionality. We'll be creating some sample workflow stages, an empty workflow that we can build on later, and a sample enterprise project type. We can then use these items in the articles that follow to demonstrate some of the workflow capabilities available for Project Web App. Create sample workflow stages First, we'll create some Project Web App workflow stages for use in the workflow demonstration articles that follow. We'll create the following stages: STAGE NAME PHASE 1 - Propose idea Create 2 - Request review Select 3 - Execute Manage 4 - Cancelled Finished Use the following procedure to create each of the stages in the table above. Follow the procedure once for each stage. To create a stage 1. In Project Web App, click Settings > PWA Settings. 2. Under Workflow and Project Detail Pages, click Workflow Stages. 3. Click New Workflow Stage. 4. In the Name box, type a name for the stage as shown in the table above. 5. Choose a phase from the Workflow Phase dropdown list as shown in the table above. 6. In the Visible Project Detail Pages section, select Project Information and click > to add it to the Selected Project Details Pages list. 7. Leave the other options at their default values and click Save. Publish an empty workflow to Project Web App Next, we'll create an empty workflow. We'll be adding to the workflow later, but right now we need the empty container to hook up to the enterprise project type that we'll create next. To create and publish a workflow

467 1. Start SharePoint Designer. 2. Click Open Site. 3. Type the URL of your Project Web App site, and then click Open. 4. On the left, click Workflows. 5. On the ribbon, click Site Workflow. 6. Type Sample Workflow for the name. 7. Ensure that SharePoint 2013 Workflow - Project Server is selected as the Platform Type. 8. Click OK. 9. On the ribbon, click Publish. 10. Close SharePoint Designer. Create an enterprise project type With the workflow published, we can create a sample enterprise project type. To create a sample enterprise project type 1. In Project Web App, click Settings > PWA Settings. 2. Under Workflow and Project Detail Pages, click Enterprise Project Types. 3. Click New Enterprise Project Type. 4. Type Sample Project Type for the name. 5. Choose Sample Workflow (the workflow that we just created) from the Site Workflow Association dropdown list. 6. Choose Project Information from the New Project Page dropdown list. 7. Click Save. Explore workflow functionality With the sample stages and workflow in place, we can take a closer look at workflow functionality in Project Web App. See the following articles to try out some of the Project Web App features: 1. Have a workflow wait for a Project Web App event 2. Set the stage status in a Project Web App workflow 3. Add a custom field to a project detail page 4. Assign an approval task in a workflow 5. Customize approval options for Project Web App workflows You can read these articles in any order, but the order listed above represents simplest to most complex.

468 Have a workflow wait for a Project Web App event 12/13/ min to read Edit Online Summary: Learn how to have a workflow wait for a Project Web App event. Applies to: Project Server 2016, Project Server 2013 You can set a Project Web App workflow to pause and wait for a Project event before proceeding. The workflow can be set to wait for when the project is checked in, committed, or submitted. In this article we'll take a look at configuring a workflow to pause until the associated project is submitted. This is useful if you want to gather project information and then have the project sent for approval after the information gathering is complete. Before you begin Before starting, make sure: If you are using an on-premises deployment of Project Server, you have set up the SharePoint 2013 workflow platform. You have created the sample workflow, stages, and enterprise project type as described in Create a sample Project Web App workflow. Configure a workflow to wait for a Project event First, we'll create a simple workflow with two stages and have it wait for the project to be submitted before moving from the first stage to the second. We'll be using the Sample Workflow that you created in Create a sample Project Web App workflow to build a workflow that looks like this: If you've completed the procedures in other articles in this series, you may already have part of this workflow in place. The complete steps for creating this workflow are in the following procedure. To have a workflow wait for a Project event 1. Start SharePoint Designer. 2. Connect to your Project Web App site. 3. On the left, click Workflows.

469 4. Click Sample Workflow. 5. Click Edit workflow. 6. On the ribbon, click Stage, and then click 1 - Propose idea. 7. Place the orange cursor in the top section of Stage 1 and, on the ribbon, click Action, and then, under Project Web App Actions, click Wait for Project Event. 8. Click this project event, and choose Event: When a project is submitted from the dropdown menu. 9. Place the orange cursor below Stage 1, click Stage, and then click 2 - Request review. 10. Place the orange cursor in the Transition to stage area of Stage 1, and then, on the ribbon, click Action, and then click Go to a stage. 11. Click a stage, and then choose 2 - Request review from the dropdown menu. 12. Place the orange cursor in the Transition to stage area of Stage 2, and then, on the ribbon, click Action, and then click Go to a stage. 13. Click a stage, and then choose End of Workflow from the dropdown menu. 14. On the ribbon, click Publish. Test it out With the workflow published, the next thing to do is to create a test project to see if the workflow is being properly paused in the first stage. To create a project 1. In Project Web App, in the left navigation, click Projects. 2. On the ribbon, click the Projects tab. 3. Click New, and then click Sample Project Type. 4. Name the project Wait for an event, and then click Save. The Workflow Status page should show the workflow stages as 1 - Propose idea. (You may need to wait a minute or two and refresh the page if you don't see this right away.) The workflow is waiting for a Submit event, so the next step is to submit this project. To submit a project 1. On the Workflow Status page, on the ribbon, click Submit. 2. Click OK to confirm. The Workflow Status page should show the workflow stage as 2 - Request review, confirming that the workflow has moved forward after seeing the submit event. In the next article, we'll look at how to use the workflow status information to leave messages for your users. See also Create a sample Project Web App workflow Set the stage status in a Project Web App workflow Add a custom field to a project detail page

470 Assign an approval task in a workflow Customize approval options for Project Web App workflows

471 Set the stage status in a Project Web App workflow 12/13/ min to read Edit Online Summary: Learn how to set the stage status in a Project Web App workflow to leave a message for your users. Applies to: Project Server 2016, Project Server 2013 You can use the Project Stage Status feature in a Project Web App workflow to leave a message for your Project Web App users while the workflow is running. This can be useful if you want to tell your users about actions that they must complete in order to advance the workflow. Before you begin Before starting, make sure: If you are using an on-premises deployment of Project Server, you have set up the SharePoint 2013 workflow platform. You have created the sample workflow, stages, and enterprise project type as described in Create a sample Project Web App workflow. Set a status update in a workflow We'll be using the Sample Workflow that you created in Create a sample Project Web App workflow to build a workflow that looks like this: If you've completed the procedures in other articles in this series, you may already have part of this workflow in place. The complete steps for creating this workflow are in the following procedure. To set the stage status in a Project Web App workflow 1. Start SharePoint Designer. 2. Connect to your Project Web App site. 3. On the left, click Workflows. 4. Click Sample Workflow. 5. Click Edit workflow. 6. On the ribbon, click Stage, and then click 1 - Propose idea.

472 7. Place the orange cursor in the top section of Stage 1 and, on the ribbon, click Action, and then, under Project Web App Actions, click Wait for Project Event. 8. Click this project event, and choose Event: When a project is submitted from the dropdown menu. 9. Place the orange cursor under Wait for Event: When a project is submitted. 10. On the ribbon, click Action, and then under Project Web App Actions, click Set Project Stage Status. 11. Click the first this value link and choose None from the dropdown list. 12. Click the second this value link, and in the text box, typeproject submitted. 13. Place the orange cursor below Stage 1, click Stage, and then click 2 - Request review. 14. Place the orange cursor in the Transition to stage area of Stage 1, and then, on the ribbon, click Action, and then click Go to a stage. 15. Click a stage, and then choose 2 - Request review from the dropdown menu. 16. Place the orange cursor in the Transition to stage area of Stage 2, and then, on the ribbon, click Action, and then click Go to a stage. 17. Click a stage, and then choose End of Workflow from the dropdown menu. 18. On the ribbon, click Publish. Test it out With the workflow published, the next thing to do is to create a test project to see if the status is being set correctly. To create a project 1. In Project Web App, in the left navigation, click Projects. 2. On the ribbon, click the Projects tab. 3. Click New, and then click Sample Project Type. 4. Name the project Set the stage status, and then click Save. The Workflow Status page should show the workflow stages as 1 - Propose idea. (You may need to wait a minute or two and refresh the page if you don't see this right away.) Expand All Workflow Stages at the bottom of the page. The Status Info should be empty for the 1 - Propose idea stage. Next, we'll submit the project to trigger the status update that we included in SharePoint Designer. To submit a project 1. On the Workflow Status page, on the ribbon, click Submit. 2. Click OK to confirm. The Workflow Status page should show the workflow stages as 2 - Request review. Expand All Workflow Stages at the bottom of the page. The Status Info should be Project submitted for the 1 - Propose idea stage. This is the custom text that we included in the workflow. In the next article, we'll look at how to add a custom field to a project detail page.

473 See also Create a sample Project Web App workflow Have a workflow wait for a Project Web App event Add a custom field to a project detail page Assign an approval task in a workflow Customize approval options for Project Web App workflows

474 Add a custom field to a project detail page 12/13/ min to read Edit Online Summary: Learn how to add a custom field to a project detail page. Applies to: Project Server 2016, Project Server 2013 By adding a custom field to a project detail page, you can collect customized project information as part of a Project Web App workflow. In this article we'll look at an example of collecting a cost estimate in the first stage of the workflow. Before you begin Before starting, make sure: If you are using an on-premises deployment of Project Server, you have set up the SharePoint 2013 workflow platform. You have created the sample workflow, stages, and enterprise project type as described in Create a sample Project Web App workflow. Create the custom field In this example, we'll create a custom field called Project Cost that we'll use in the workflow to gather preliminary cost information about the project. To create a custom field 1. In Project Web App, click Settings > PWA Settings. 2. Under Enterprise Data, click Enterprise Custom Fields and Lookup Tables. 3. Under Enterprise Custom Fields, click New Field. 4. For Name, type Project Cost. 5. Under Entity and Type, choose Cost from the Type dropdown list. 6. Under Behavior, select the Behavior controlled by workflow check box. 7. Click Save. Add the custom field to a project detail page Once the field has been created in Project Web App, we need to add it to the project detail page. In this example, we'll use the ProjectInformation page that comes with Project Web App. To add a custom field to a project detail page 1. In Project Web App, click Settings > PWA Settings. 2. Under Workflow and Project Detail Pages, click Project Detail Pages. 3. On the Project Detail Pages page, click the ProjectInformation page. 4. On the ribbon, on the Page tab, click Edit Page. 5. In the upper right corner of the Basic Info area, open the dropdown menu and choose Edit Web Part.

475 6. Under Displayed Project Fields, click Modify. 7. In the Project Fields list, find the Project Cost field that you just created, and then click the add ( >) button to add it to the Selected Project Fields list. 8. Click OK. 9. Scroll down until you see the OK button and click OK. 10. On the ribbon, click Stop Editing. Build a workflow We've added the custom field to the project detail page, but by default it's not a required field on that page. Required fields are configured as part of the workflow stage in which the project detail page appears. Because we want to use the field in a workflow calculation, we need to make sure it's a required field by modifying the stage. To modify a stage 1. In Project Web App, click Settings > PWA Settings. 2. Under Workflow and Project Detail Pages, click Workflow Stages. 3. Click the 1 - Propose idea stage. 4. Scroll down to the Required Custom Fields area. 5. Select Project Cost in the Choose Custom Fields list and click the add ( >) button. 6. At the bottom of the page, click Save. Building the workflow itself is the next step. We'll be using the Sample Workflow that you created in Create a sample Project Web App workflow to build a workflow that looks like this: If you've completed the procedures in other articles in this series, you may already have part of this workflow in place. The complete steps for creating this workflow are in the following procedure.

476 To create a workflow 1. Start SharePoint Designer. 2. Connect to your Project Web App site. 3. On the left, click Workflows. 4. Click Sample Workflow. 5. Click Edit workflow. 6. On the ribbon, click Stage, and then click 1 - Propose idea. 7. Place the orange cursor in the top section of Stage 1 and, on the ribbon, click Action, and then, under Project Web App Actions, click Wait for Project Event. 8. Click this project event, and choose Event: When a project is submitted from the dropdown menu. 9. Place the orange cursor below Stage 1, click Stage, and then click 3 - Execute. 10. Place the orange cursor below Stage 3, click Stage, and then click 4 - Cancelled. 11. Place the orange cursor in the Transition to stage area of Stage 1, and then, on the ribbon, click Condition, and then click If any value equals value. 12. Click the first value link, and then click fx. 13. Leave the Data source set to Project Data and choose Project Cost from the Field from source dropdown list. 14. Click OK. 15. Click the equals link, and then choose is greater than from the dropdown list. 16. Click the second value link, and type10000 in the text box. 17. Place the orange cursor in the If branch of the If / Else statement. 18. On the ribbon, click Action, and then choose Go to a stage. 19. Click the a stage link, and then choose 4 - Cancelled. 20. Place the orange cursor in the Else branch of the If / Else statement. 21. On the ribbon, click Action, and then choose Go to a stage. 22. Click the a stage link, and then choose 3 - Execute. 23. Click a stage, and then choose 3 - Execute from the dropdown menu. 24. Place the orange cursor in the Transition to stage area of Stage 3, and then, on the ribbon, click Action, and then click Go to a stage. 25. Click a stage, and then choose End of Workflow from the dropdown menu. 26. Place the orange cursor in the Transition to stage area of Stage 4, and then, on the ribbon, click Action, and then click Go to a stage. 27. Click a stage, and then choose End of Workflow from the dropdown menu. 28. On the ribbon, click Publish. Test it out

477 Now that the workflow has been published, let's create a test project and see how our custom field for project cost works. To create a project 1. In Project Web App, in the left navigation, click Projects. 2. On the ribbon, click the Projects tab. 3. Click New, and then click Sample Project Type. 4. Name the project Custom Field, and then type 5000 in the Project Cost field. 5. Click Save. Note that the Current Workflow Stage is 1 - Propose idea. Click Submit on the ribbon to move the project to the next stage. Because the project cost is below the $10,000 limit that we set in the workflow, the Current Workflow Stage moves to 3 - Execute. Create another project, this time using for the Project Cost field. Note that the Current Workflow Stage moves to 4 - Cancelled when you submit the project because the cost exceeds the $10,000 limit. In the next article, we'll take a look at assigning an approval task in a workflow. See also Create a sample Project Web App workflow Have a workflow wait for a Project Web App event Set the stage status in a Project Web App workflow Assign an approval task in a workflow Customize approval options for Project Web App workflows

478 Assign an approval task in a workflow 12/13/ min to read Edit Online Summary: Learn how to add an approval task to a Project Web App workflow. Applies to: Project Server 2016, Project Server 2013 By including an approval task in your Project Web App workflow, you can ensure that your projects receive proper approval before they get underway. In this article, we'll look at an example of using an approval task in a workflow to allow selected users to approve or reject a project. Before you begin Before starting, make sure: If you are using an on-premises deployment of Project Server, you have set up the SharePoint 2013 workflow platform. You have created the sample workflow, stages, and enterprise project type as described in Create a sample Project Web App workflow. Create a workflow with an approval task We'll be using the Sample Workflow that you created in Create a sample Project Web App workflow to build a workflow that looks like this:

479 If you've completed the procedures in other articles in this series, you may already have part of this workflow in place. The complete steps for creating this workflow are in the following procedure. To create a workflow 1. Start SharePoint Designer. 2. Connect to your Project Web App site. 3. On the left, click Workflows. 4. Click Sample Workflow. 5. Click Edit workflow. 6. On the ribbon, click Stage, and then click 1 - Propose idea. 7. Place the orange cursor in the top section of Stage 1 and, on the ribbon, click Action, and then, under Project Web App Actions, click Wait for Project Event. 8. Click this project event, and choose Event: When a project is submitted from the dropdown menu. 9. Place the orange cursor below Stage 1, click Stage, and then click 2 - Request idea. 10. Place the orange cursor below Stage 2, click Stage, and then click 3 - Execute. 11. Place the orange cursor below Stage 3, click Stage, and then click 4 - Cancelled. 12. Place the orange cursor in the Transition to stage area of Stage 1, and then, on the ribbon, click Action, and then click Go to a stage. 13. Click the a stage link, and then choose 2 - Request review from the dropdown list. 14. Place the orange cursor in the top half of Stage On the ribbon, click Action, and then, under Task Actions, click Start a task process. 16. Click the these users link. 17. On the Start a Task Process page: 18. Click the ellipsis (...) for Participants and add the name of the user to whom you want to assign the project approval task. 19. For Task Title, click fx, choose a Data source of Project Data, a Field from source of Project Name, and click OK. 20. Click OK. 21. Place the orange cursor in the Transition to stage section of Stage Click Condition and select If any value equals value. 23. Click the first value link, and then click fx. 24. Choose a Data source of Workflow Variables and Parameters and a Field from source of Variable: Outcome and click OK. 25. Click the second value link and choose Approved from the dropdown list. 26. Place the orange cursor in the If branch of the If / Else statement. 27. On the ribbon, click Action, and then choose Go to a stage. 28. Click the a stage link, and then choose 3 - Execute.

480 29. Place the orange cursor in the Else branch of the If / Else statement. 30. On the ribbon, click Action, and then choose Go to a stage. 31. Click a stage, and then choose 4 - Cancelled from the dropdown menu. 32. Place the orange cursor in the Transition to stage area of Stage 3, and then, on the ribbon, click Action, and then click Go to a stage. 33. Click a stage, and then choose End of Workflow from the dropdown menu. 34. Place the orange cursor in the Transition to stage area of Stage 4, and then, on the ribbon, click Action, and then click Go to a stage. 35. Click a stage, and then choose End of Workflow from the dropdown menu. 36. On the ribbon, click Publish. Test it out With the workflow published, we can create a sample project to see how the approval task works. To create a project 1. In Project Web App, in the left navigation, click Projects. 2. On the ribbon, click the Projects tab. 3. Click New, and then click Sample Project Type. 4. Name the project Assign an approval task, and then click Save. 5. On the Workflow Status page, click Submit, and then click OK to confirm. Once the project has been created and submitted, you'll notice that the Current Workflow Stage is 1 - Propose idea. The workflow will pause here until the user to whom you assigned the approval task approves or rejects the project. Let's take a look at what happens when the user approves the task. To approve a task 1. Log into Project Web App as the user to whom you assigned the task. 2. In Project Web App, in the left navigation, click Approvals. 3. On the ribbon, click Workflow Approvals. 4. On the Workflow Tasks list, click All Tasks. 5. Click Assign an approval task. 6. On the ribbon, click Edit. 7. Click Approved. Notice that once the task has been approved, the Current Workflow Stage is 3 - Execute. Try creating another project, and this time choose Rejected for the approval task. Note that the Current Workflow Stage is 4 - Cancelled. In the next article, we'll look at how to add an additional approval option to the approval task. See also

481 Create a sample Project Web App workflow Have a workflow wait for a Project Web App event Set the stage status in a Project Web App workflow Add a custom field to a project detail page Customize approval options for Project Web App workflows

482 Customize approval options for Project Web App workflows 12/13/ min to read Edit Online Summary: Learn how to add additional approval options to a Project Web App workflow approval task. Applies to: Project Server 2016, Project Server 2013 When using approval tasks in your workflows, it is often desirable to have additional options beyond Approved and Rejected. For example, you may want those submitting the proposal to do some additional groundwork on the project and then resubmit before you make the final Approved or Rejected decision. In this article, we'll look at how to add a third option we'll call it Revise and Resubmit to the list of options in the workflow approval task. Before you begin Before starting, make sure: If you are using an on-premises deployment of Project Server, you have set up the SharePoint 2013 workflow platform. You have created the sample workflow, stages, and enterprise project type as described in Create a sample Project Web App workflow. Add a new task approval option The first thing that we need to do is to add the new Revise and Resubmit option to the existing list of approval options. This is done in the site settings for the Project Web App site. To modify the task approval options 1. In Project Web App, click Settings, and then click Site settings. 2. Under Web Designer Galleries, click Site content types. 3. Under List Content Types, click Workflow Task (SharePoint 2013). 4. Under Columns, click Task Outcome. 5. Click the Edit site column link. 6. In the Type each choice on a separate line box, addrevise and Resubmit on a separate line between Approved and Rejected. 7. Click OK. Create the workflow We'll be using the Sample Workflow that you created in Create a sample Project Web App workflow to build a workflow that looks like this:

483 If you've completed the procedures in other articles in this series, you may already have part of this workflow in place. The complete steps for creating this workflow are in the following procedure. To create a workflow 1. Start SharePoint Designer. 2. Connect to your Project Web App site. 3. On the left, click Workflows. 4. Click Sample Workflow. 5. Click Edit workflow. 6. On the ribbon, click Stage, and then click 1 - Propose idea. 7. Place the orange cursor in the top section of Stage 1 and, on the ribbon, click Action, and then, under Project Web App Actions, click Wait for Project Event. 8. Click this project event, and choose Event: When a project is submitted from the dropdown menu. 9. Place the orange cursor below Stage 1, click Stage, and then click 2 - Request idea. 10. Place the orange cursor below Stage 2, click Stage, and then click 3 - Execute. 11. Place the orange cursor below Stage 3, click Stage, and then click 4 - Cancelled.