Force Rebuild of the Project Server Reporting Database

Background

The Microsoft Office Project Server 2007 Reporting database can become corrupt at times causing general queue job failures when publishing projects when invoking the Reporting message processor throwing exceptions that cite FOREIGN KEY constraint conflicts. Sometimes these are spurious and random in nature, and you can correct them simply by forcing a rebuild of the Project Server 2007 Reporting database.

Resolution

To force a rebuild of the Project Server 2007 Reporting Database, follow these steps:

1. Logon to Project Web Access with Administrator credentials
2. Select Administrative Backup from the Database Administration section on the Server Settings Page in Project Web Access
3. In the Items for Backup section of the Backup page, select the checkbox for Enterprise Custom Fields and then click the Backup button and click the OK button when prompted by the system
4. Select Administrative Restore from the Database Administration section on the Server Settings Page in Project Web Access
5. Choose Enterprise Custom Fields from the Choose Item selector on the Restore page
6. Click the Restore button and then click the OK button when prompted by the system

Allow time for the reporting rebuild job to run. You can track the state of this job on the Manage Queue page.

 

Discontinued features and modified functionality in Microsoft Project Server 2010

Applies to: Microsoft Project Server 2010

 

If you are familiar with previous versions of Microsoft Project Server, the following sections describe features and functionality that have been discontinued or changed in Microsoft Project Server 2010.

Project Portfolio Server changes

Project Server and Project Portfolio Server are no longer two separate products. Relevant portfolio functionality from Project Portfolio Server has been merged into Project Server 2010. The following Project Portfolio Server 2007 features and functionality were discontinued or changed for Project Server 2010:

• Application portfolio management   This includes tracking and managing applications.
• Audit Trail   Workflow activity was previously made available from the Audit Trail link in the Workflow module. In Project Server 2010, this information is available in the Workflow History list, which can be accessed from the Additional Workflow Data link in the All Workflow Stages section.
• Benefits estimating   This includes estimating and tracking financial and non-financial benefits.
• Organizational hierarchy and aggregates   This includes a security-based hierarchical data grouping and aggregation. In Project Server 2010, departments have been added to enable hierarchical data grouping based on organizational structure.
• Dynamic charting   This includes the Chart Wizard, which allows for ad-hoc interactive chart creation, including bubble chart modeling. In Project Server 2010, Excel Services support has been added, providing a new method of dynamic reporting.
• Financial management   This includes time-phased budget, actual, and forecast cost tracking. In Project Server 2010, use custom fields and Excel Services to enable cost functionality for simple estimation, tracking, and forecasting costs. Solutions for more complex estimating, tracking, and forecasting costs are offered by Microsoft partners.
• Insight analysis   This enabled users to get specific details into the factors that impact a specific portfolio selection.
• Decision dashboard   This enabled users to make selection decisions supported by a rich dashboard with live grouping and charting.
• Sensitivity analysis   This enabled users to take a portfolio selection through various what-if scenarios and figure out how close a project was to being selected.
• Snapshotting and versioning   This enabled users to create cost, resource, and benefit snapshots at any given point in time. In Project Server 2010, reporting and base-lining can be used to capture data snapshots.
• Surveys   This includes flexible, user-definable survey forms, on subjects related to risk, architectural fit, and operational performance.

 

Other changes

In addition to the portfolio functionality changes, the following list describes other changes implemented in Project Server 2010.

• Outlook add-in    The Outlook add-in for Project Server has been discontinued in Project Server 2010. The existing add-in can still connect to Project Server 2010, however it has not been updated for this release. Instead, Project Server 2010is integrated with Exchange Server, so that users no longer need to download a separate COM add-in. The timesheet functionality that was present in the Outlook add-in has been discontinued.
• Activity plans and personal projects    included the ability to create and manage activity plans, also known as lightweight projects, and personal projects from within Project Web Access. Instead, Project Server 2010 supports editing any project on the server using a rich, new grid control in Project Web App.
• Color indicators on the My Tasks page   Color indicators on the My Tasks page have been replaced with the text from the tool tip for the indicator, paired with a background color for the text.
• Data analysis    The underlying technology used for data analysis in previous versions, Office Web Components, has been discontinued. In Project Server 2010, this technology has been replaced with Excel Services.

SharePoint Workflow Conductor 1.5 - Bamboo Solutions

Common Engineering Criteria Scorecards

Microsoft server products comply with the common engineering criteria.

Scorecards report each server product’s compliance status for the established common engineering criteria.

Link: http://browse.eppmsolutions.com/scorecards2010

Report instantly with Project 2007

Microsoft Project to Atlassian JIRA

Microsoft Project to Atlassian JIRA Integration
The Connector is a Microsoft Project extension plug-in that will allow connection directly from Microsoft Project to Atlassian JIRA. Create a project plan using Microsoft Project and directly import tasks from JIRA. Use JIRA for task management and quickly and easily sync between the two systems. The Connector provides direct integration with Microsoft Project creating a JIRA toolbar right in Project. From this toolbar, you have access to a variety of JIRA functionality like importing, updating resource assignments, due dates and task descriptions.

Rename a Project Workspace

When a project plan is renamed in Project Server 2007, the system does not change the name of the Project Workspace associated with the project.

To change the name of the Project Workspace:

1.       Go to the workspace

2.       Go to Site Actions > Site Settings

3.       Under the Look and Feel menu section select Title, description, and icon

4.       Change the name and click "OK"

 

Project Server 2007 CALs

Project Server 2007 Client Access Licenses (CALs) are required for each device or user that accesses the features and services of Project Server 2007, for example to use the thin Web client Project Web Access, Project Web Parts in SharePoint, or connecting customized client interfaces.
The CAL enables Project Web Access, the web client to the EPM Solution, which enables users to view, analyze and report on information including timesheets as well as create project proposals and activity plans. This also includes the administrative user interface.

Please refer to the licensing brief “Multiplexing — Client Access License (CAL) Requirements” and the Product Use Rights agreement for additional details on CALs.

Project Server 2007 External Connector Overview

The Project Server 2007 External Connector is an optional product for the EPM Solution that permits non-employees such as partners to collaborate on projects.

To allow your business partners or customers to access your network, there are two licensing options:

• Acquire Windows CALs for each of your external users.
• Acquire External Connector (EC) licenses for each server that will be accessed by your external users.

An external user is a person who is not an employee, or similar personnel of the company or its affiliates, and is not someone to whom you provide hosted services using the server software.

Delete Project Workspace Template

Delete a Project Workspace Template:

1. Log directly on to the Project Server machine and open a command prompt window: Start > Run > cmd > OK
2. Change the command prompt directory to "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"
3. Execute the following STSADM command, replacing the title of the template (shown here as "Custom Project Workspace 01") with the title of your template to be deleted:
stsadm -o deletetemplate -t "Custom Project Workspace 01"
The following message should be displayed:
Operation completed successfully.
IIS must be restarted before this change will take effect. To restart IIS, open a command prompt window and type iisreset.
4. Repeat the STSADM deletetemplate command for each Project Workspace template that you would like to remove from the system, then execute an iisreset from the command prompt.
iisreset
The following message should be displayed:
Attempting to stop...
Internet services successfully stopped
Attempting to start...
Internet services successfully restarted
Return to the PWA Project Workspace Provisioning Settings page
PWA > Server Settings > Project Workspace Provisioning Settings
In the Default Project Workspace Template drop-down list, you should no longer see the templates that you removed using the STSADM command.

Sync PWA App Root Site with Project WSS Workspaces

Steps to initiate ‘User Synchronization for Project Web Access App Root Site and Project WSS Workspaces’

1. Create a new Category from on Server Settings.

2. Click Manage Groups and add all users to this group except the currently logged in user.

3. Click save.

4. Revert the changes. Delete the newly created category.

5. Check if ‘User Synchronization for Project Web Access App Root Site and Project WSS Workspaces’ has succeeded in the project queue.

6. Synchronize the Project Workspaces from Server Settings >> Project Workspaces.

Bug in SP2: Project 2007 Client Damages Project Server E-Global

Project Server 2007 Security

Product Expiration Date Activated Post SP2 Install on Microsoft Office Servers

During the installation of the 2007 Microsoft Office Servers SP2, a product expiration date is activated incorrectly. This means that any of the following products will expire 180 days after Service Pack 2 is deployed, as if it was a trial installation.

· Microsoft Office SharePoint Server 2007

· Microsoft Office SharePoint Server 2007 for Internet Sites

· Microsoft Office Project Server 2007

· Microsoft Search Server 2008

· Microsoft Search Server 2008 Express

· Microsoft Office Forms Server 2007

The activation of the expiration date will not affect the regular function of these products until the expiration date passes, 180 days after Service Pack 2 is deployed. If the product expires, it will not affect data, configuration, or application code. However, it will make the Office Server product inaccessible for end-users. Office SharePoint Server Trial with Enterprise Client Access License, or a similar product, is displayed on the Convert License page.

This issue occurs because of the installation of the 2007 Microsoft Office Servers Service Pack 2. All installations of this service pack will result in this issue.

To resolve this issue manually, type the product key on the Convert License Type page. To do this, follow these steps:

1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.

2. Click Operations Tab.

3. Click Convert License Type.

4. In the Enter the Product Key text box, type your product identification number, and then click OK.

5. The License Synchronizer Job will run on all computers in the farm after a few moments. After all the computers have updated their license from the timer job, the Convert License Type page will reflect the correct license.

Note: The manual solution will not work for Microsoft Search Server 2008 Express because it does not use a product key.

In case multiple SKUs are installed, provide the product key for the most inclusive product. Use the product key from the highest-listed product in the following ordered list:

· Microsoft Office SharePoint Server 2007

· Search Server 2008, Search Server 2008 Express, or Microsoft Office SharePoint Server 2007 for Search

· Microsoft Office Project Server 2007

· Windows SharePoint Services 3.0 is not affected.

Microsoft has confirmed that this is a bug in the Microsoft products listed above.

OWSTIMER Issue in Restore

Nasty Restore Problem (OWSTIMER Issue/SPUpdatedConcurrencyException/SPDatabaseServiceInstance)

"An update conflict has occurred, and you must re-try this action. The object SPSearchDatabase Name=WSS_Search_epm2007demo Parent=SPDatabaseServiceInstance is being updated by EPM2007DEMO\FarmAdmin, in the OWSTIMER process, on machine EPM2007DEMO. View the tracing log for more information about the conflict."

"Object WSS_Search_epm2007demo failed in event OnPostRestore. For more information, see the error log located in the backup directory. SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPSearchDatabase Name=WSS_Search_epm2007demo Parent=SPDatabaseServiceInstance is being updated by EPM2007DEMO\FarmAdmin, in the OWSTIMER process, on machine EPM2007DEMO. View the tracing log for more information about the conflict."

1. Start SharePoint 3.0 Central Administration (you might have to pause the Windows SharePoint Timer service before you can actually get there -especially if you’re using a VPC – for whatever reason, OWSTIMER.EXE can easily soak up whatever CPU cycles you have…)
2. Go to Operations
3. Under Logging and Reporting, choose Diagnostic Logging.
4. Under Event Throttling, choose All as the category (this may be unnecessary, as it could be the default, but judging by the amount oflogging, it probably isn’t)
5. Under Trace Log, set “Number of log files” to something reasonable – say, 5. You can leave “Number of minutes…” to be 30, unless you want those 5 files to be smaller in size. By default number of minutes is 30.
--OR--
1. In you backup folder open spbackup.xml
2. Search for Microsoft.SharePoint.Search.Administration.SPSearchDatabase
3. Under node look for
Key="STATE.xml">0000000A.bak
NOTE: is an actual GUID, not the string “”
4. Take not of the file contained in CDATA (i.e. 0000000A.bak).
The file name can change from backup to backup
5. In your backup folder open 0000000A.bak using a standard text editor
6. Locate node
7. Change value to a date in the future tomorrow could be a good date)
8. Save the text file.
9. Perform the restore operation as you would usually do.
--OR--
An update conflict has occurred, and you must re-try this action.
http://support.microsoft.com/kb/939308

Project End

A few things that should be thought about when getting close to the end of a project.

#1: Finalize Testing

#2: Finalize Training

#3: Validate Deliverables

#4: Get Project Signoff

#5: Release The Team

#6: Analyze Actual Vs. Planned

#7: Archive Documentation

#8: Ensure Contract Closure

#9: Conduct a Postmortem Meeting

#10: Perform a self assessment

If done, it always makes the transition to the next project smoother.

Issues with Project Server 2007 (SP2 + April CU+ SQL Server 2005 SP3)

Issue #1:

Capacity settings might get changed by the upgrade.
If that looks ok it might be good to force a refresh of the reporting DB (backup enterprise fields and then restoring them). However this "fix" can create other problems, like errors building the OLAP cube if it contains changed outline codes.

Link to source

Migrate MOSS & MOPS 2007 With Workspaces

Steps to migrate Project Server 2007 with workspaces for the SharePoint Administrator

SharePoint 2007 and Project Server 2007 can be installed together in the same "farm" environment. This can provide a very powerful solution for both collaboration and Project management. But take care, there are a few things you really need to know about this marriage. This post only addresses migrating your Project server instance (PSI) from one SSP to another, both within same farm or a different farm such as; moving from Production to Development, Test or Staging.

For the general SharePoint Admin superhero, project server can be like Kryptonite, in that it makes the stsadm backup/restore feature useless on its site collection. I am going to share a few things that I have learned along the way.

1. When you create a Project server 2007 instance, a managed PATH is created automatically.
2. A site collection is created and visible from central admin in the site collection list. It is not you average site collection though.
http://CentralAdmin:port/_admin/SiteCollections.aspx?ReturnSelectionPage=/_admin/applications.aspx
3. You can not backup this site collection using the Standard STSADM -backup tools.
Now, I am told that a FULL Farm backup does capture Project server, but I have not had to test that theory out.
4. Run the Re-linker tool over and over... and over... and over...

As a SharePoint administrator of such a farm, you will undoubtedly, at some point have to rebuild your SSP, and or migrate your project server instance. This can be very painful, or simply a pain. For me, as I am sure it is for a very many people, it has been a learn as you go process. I have trashed my share of PWA instances before coming up with this procedure. I have searched all over, and found some very basic steps on what to do, but never any full start to finish article.

Migrating a SharePoint Web application from one SSP to another is a fairly straight forward process of reassigning association for the web application. And a PWA instance should follow its it parent web application through this process. But if it doesn't or there are other issues complicating the process. I would greatly suggest having your PWA instance backed up in such a way that you can re-provision it quickly, and lose no data. The procedure I outline below can also be used as your regular backup routine for Project server.

**************************************************************
Disclaimer:This is free advise given in good faith and NO guarantees. You may/maynot follow them. Choose to follow at your OWN RISK only. Always backup the farm and test in non-production environments first before affecting the production. This article assumes MOSS 2007 x64 Standard, Project server x64 2007, running on windows 2003 R2 x64, besides your familiarity with basic SharePoint 2007 Administration.
**************************************************************

1. Backup all databases and sites/workspaces that will be affected.
First thing to do is follow your normal steps for Downtime procedure.

Take the following backups:
a. SQL Standard backups of all Databases.
b. STSADM Full Farm Backup.

I have not found a need to backup IIS settings, or web.configs... The reason is, I force developers to make all changes to the web.config using WSP packaged deployments. But if you have all ready made manual changes to IIS, I would at least back up anything you have modified. But I really really suggest making those changes via package deployment, that makes your life SOOO much easer.

Backup Project web access DBs (Published, Draft, Archive, and reporting) using Standard SQL tools. This is needed mainly if you intend on moving the PWA instance to a new farm or different web application. If you are just moving the PWA instance with it's parent web application to a new SSP in the same farm, this step is not required, but is still advisable.

Export all PWA workspaces - (pick your own options, I use these)

- stsadm -o export -url "http://webapp/site/pwa/workspace URL/" -filename \\UNC\PATH\file.bak -includeusersecurity -versions 4

You can script this action once you determine all of the URLs and file Paths. be sure to catch subsites. However, I would suggest making it a policy not to have subsites on the Project workspaces. It creates added complexity when trying to recover from disaster. And even preparing for DR becomes a nightmare.

2. Create the new SSP

Configure the user profile import connections, and schedule, and any customizations that you may need to have ready to go. But be cognizant of your available storage, if you have the space available, you can go ahead and start up your new content sources, but at the very least, create search scopes, and best bets, keywords, targeted audiences, all of that has to be re-done by hand if you don't/can't restore a previously backed SSP, but backup and restore of the SSP is an entirely different article. DO NOT create a new PWA at this point.

3. Configure search, I hold of on crawling until the SSP is ready to use, but that is really up to you. If you know you have a lot to crawl, you may want to go ahead and start the process. But be sure you have the space for both your SSP search database, but also the search index that is propagated to your web front ends.

User Profile imports, I would run this in the new SSP just before actually moving the web applications over... Depending you situation, you can decide.

Also, any Special BDC settings, and other customization should be replicated in the new SSP.

4. Change association of the web application that the project server instance uses to the new SSP.

If all you want to do is move the current PWA instance and parent web application to the new SSP, then you can follow the normal process of changing the SSP association in the Shared service administration page "http://centraladmin:port/_admin/managessp.aspx" Once the association is changed it takes the PWA instance 5-10 minutes to re-provision/re-sync with the new SSP... Depending on your hardware, this could take longer, but remember, you shouldn't be doing this in a live system, you should be in a downtime window so that no users are affected. And that is that for a simple SSP migration, since you finished so early, you can take that backup from section 1. and restore it to a sandbox or another test system. Just to show off. :)

You may have restart the project server Queue service in windows if the Queue gets stuck because of the move.

5. Restoring a PWA instance to a New location or farm.

To this point we have been having fun... but now comes the pain.... Not really, but it all really depends on how many projects have been loaded in your instance... For a very large installation, I can see this being a very very big PITA.

So once you have all your databases, workspaces, and such backed up from step one. We must now look at the new location. If it is with in the same FARM, then most things are taken care of, but if you are moving to a new FARM, You are gong to need to verify a few things.

A. Check the Farm version, this can be done by accessing the Servers in farm page here: "http://Centraladmin:port/_admin/FarmServers.aspx"

Be sure that the destination farm is at least the same version or higher than the source FARM, SharePoint Products and technologies can upgrade incoming Databases, but will refuse databases with a newer schema than it is currently operating. But it would be best if the versions matched, much less likely to run into any issues that way. But if it is unavoidable, then it is what it is...

B. Verify project server is installed and the service is running on all WFE and APP servers in the farm. this can be done here:

"http://Centraladmin:port/_admin/Server.aspx"

Once you decide on the location, and have restored the project server databases to farms database server. You can go in and provision the new PWA instance using the Database names and server of the new farm. Once it is provisioned, its time to check a few things before having a Project Server Functional resource verify the configuration.

1. Verify cube build, if this is the 1st time you have setup project server in this new farm, then you will need to follow the original setup procedures of setting up the DSO share or using the OLAP database method... You can read about both here:

otherwise, just verify all the cube build settings, and run a test build.
2. Verify user accounts, and that the proper accounts are active. And that any AD sync is working properly.

C. Restore Project workspaces.

The is the task that I have found to be the "real" pain... if there are only a small number or projects with workspaces, then its not too bad. But most likely, as I have found almost every project has a workspace. And the PIC will want to keep them, even if they only have 1 document. But that's another battle entirely. For this article, we will presume that all workspaces have valid data and need to be migrated. There are several ways to go about this, but I am going to share my preferred method, as I think its the best way. :)

1. Create or run a script to create the blank project workspaces.
2. Run the Project workspace re-linker tool. - And run it, and re-run it, and run it again, until all sites are re-linked. It is necessary to run the relinker tool 1st because if run after the import, it will reset all the welcome pages to the default settings and look & feel. (based on themes, templates) RelinkAllWSSSites http://myWSSserver:80 http://myProjectserver/pwa
3. Import the workspaces using the STSADM tool.

D. Disaster recovery.
I must 1st stress the need for all SharePoint Administrators to know how to successfully back and restore their farms. The best method is the FULL method, FULL farm back and FULL farm restore. Get to know this process and set yourself up to be able to do it any anytime. It will take at least a few try's to get it right, but I would not feel comfortable until this procedure is stable and in place for the farm. Should you be in a position that you have to recovery all the project workspaces, and all you have is a DB backup or even a PWA site collection, This will work for you... But basically what you need to do is to restore the backup, either recreating the site and using the restored DB, or restoring from the site collection backup. The trick is to restore it to a new location, and export the workspaces from there, and importing them into a new PWA instance created using the backups of the PWA DBs.

Move Project Server 2007 Including WorkSpaces

Assumptions:

1. Project Server is installed on New Machine to a point with the following:
i. SharePoint Central Administration with Web Application on Port 80
ii. Web Application for SSP
iii. Project Application Service is started
2. Confirm that same service pack and patches are installed on new server.
3. Backed up and then restored Project Server database to new server.
4. Backed up and then restored Content Database for Port 80 (Assuming your project server work space was on port 80)

Steps:
1. From Start » All Programs » Administrative Tools » Navigate to SharePoint 3.0 Central Administration.
2. From Operations » Under Topology and Services » Click on Services on Server » Select the Option Project Application.
3. Confirm that Project Application Service is started.
4. Under Shared Service Administration Click on Shared Services Provider Title (Eg. SharedServicesProvider1).
5. Then click on Project Web Access Sites.
6. Then click on Create Project Web Access.
7. Confirm that the same "Project Web Access Path" is specified to RESTORE AND RELINK SharePoint workspaces. (Eg. PWA or ProjectServer)
8. Enter the account info for Administrator Account and Primary Database Server.
9. Enter the name of Published Database, Draft Database, Archive database and Reporting Database (restored databases)
10. Then Click on refresh status after few minutes until the site is provisioned.
11. Then click on the site to make sure that Project Web Access is working.
12. Then click on Workspace. Message : "The PAGE not found" is expected.
13. Now Create a new web application on a different port.
14. Then navigate back to SharePoint Central Administration » Application Management » Under SharePoint Web Application Management click on Create or Extend Web Application
15. Create New Web-Application on a different port (Eg. Port number 81 or 90 or 100). It can be any port except 80.
16. After the Web application is created on the new port 81 » Navigate to SharePoint Central Administration » Application Management » Under SharePoint Web Application Management Click on Content databases.
17. Change the Web-Application to the new web application (Eg. http://servername:81/ or http://servername:90/ or http://servername:100/ )
18. Remove its Content Database of port 81 (Make Sure you are removing the content database of correct web application)
19. Click on Database name and then click on Remove Content Database > Click Ok.
20. Then add Content Database of Port 80 from Previous Server (I did restored the database as "OLD") to this web application on Port 81.
21. From the Project Server Resource kit for Project Server 2007
22. Extract it to a local folder.
23. From command prompt, browse to the local folder where resource kit is extracted.
24. Type ReLinkAllWSSSites.exe http://newservername:newport http://newservername/PWAorProjectServer
25. Browse to Project Web Access (http://newservername/PWAorProjectServer) to confirm all Projects and their SharePoint Workspace Sites work.

IE Patch-PWA Status Reports hangs-ActiveX compatibility patch for Mshtml.dll

After applying the IE Active X update contained in the April Security update (KB912812), navigating to the Status Reports page in PWA causes Internet Explorer to use 100% of the processor for several minutes. After you regain control and click on a text box, it locks up your processor again.

Microsoft has released a patch to fix this issue. You can read about and download this patch at the following URL:

Compatibility Patch for Internet Explorer for Windows XP Service Pack 2 (KB917425)