by Martin Laukkanen | Nov 24, 2011 | How to, Project 2010
One thing I always have to search for when creating a new EPT is the appropriate icon to use. I have previously found and used some of the out-of-the-box icons that can be found in any default Project Server 2010 installation and thought that I might share them here.
There is in fact a long list which I have included below (forgive me copyright gods in MS!), to use one of these icons, just update the image URL under Server Settings –> Enterprise Project Types, for example to update the default Sample Proposal with any of the icons below, simply modify the image URL under:
For a Master Project icon (taken from the image below), replace the URL above with the following:
/_layouts/inc/pwa/images/CenterMasterProject.png
Full list of icons (16×16 size only):
Enjoy!
by Martin Laukkanen | Sep 23, 2011 | Troubleshooting
I hate log noise, errors like the following:
Log Name: Application
Source: Microsoft-SharePoint Products-Project Server
Date: 23/09/2011 11:16:05 AM
Event ID: 2077
Task Category: General
Level: Error
Keywords:
User: NT AUTHORITYIUSR
Computer: server.domain.local
Description:
Failed to get language information for Project Server (https://server/PWA)
Apparently this is an error that can be ignored, hence my term “log noise”, however if you are managing large farms having hundreds or even thousands of these occur each night across a number of servers is clearly a big problem.
So I set out to resolve this one, and the cause turned out to be rather simple.
The errors occur nightly during the same window as the Full Search Crawl, so it’s not hard to find the culprit, a bit of searching in the ULS logs correlates the above with some or all of the following errors:
09/23/2011 11:16:05.26 w3wp.exe (0x194C) 0x2A74 Project Server General auvt Exception System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralSecurityAccessDenied Instructions: Pass this into PSClientError constructore to access all error information at Microsoft.Office.Project.Server.WebServiceProxy.Admin.ListInstalledLanguages() at Microsoft.Office.Project.PWA.PJLanguageInfo.EnsureLanguageInfo
Cause
The cause is simply that the Search Default Content Access Account does not have permissions in PWA. Typically said accounts would be granted a Web Application “Full Read” policy in order to index content, however although this allows the account to index all the content without issue it does result in these errors still being thrown up by the PSI.
In that sense this can be safely ignored, however if like me you need to get rid of these the solution is simple; just setup the search account in PWA. In my case on a default test PWA instance granting Team Member rights resolved 14 out of 16 of these, so some level higher than that is required to fully resolve this.
by Martin Laukkanen | Sep 3, 2011 | Project 2010, Troubleshooting
A customer of mine had this one after completing the upgrade to SP1 recently, basically all cube building would fail with the following error:
Your CBSRequest job failed. Its current state is FailedNotBlocking. It was 0% complete. It entered the queue at 09/02/2011 11:00:26.
[snip…]
The errors returned from the queue are as follows:
Error ID: 17007
Error ID: 26000
[snip…]
<class name="CBS message processor failed">
<error id="17007" name="CBSOlapDatabaseSetupFailure" uid="7d14c29d-a133-492b-baea-2e7c0bec444b" QueueMessageBody="Setting UID=00007829-4392-48b3-b533-5a5a4797e3c9 ASServerName=server ASDBName=FullCube1 ASExtraNetAddress= RangeChoice=0 PastNum=1 PastUnit=0 NextNum=1 NextUnit=0 FromDate=01/04/2010 00:00:00 ToDate=12/31/2011 00:00:00 HighPriority=True" Error="Error Setting Olap Database ‘FullCube1’ roles: Error: This method can only convert identity claims, and only when a logical conversion exists.
Parameter name: encodedClaim" />
This customer is using Claims-NTLM (ie AD users via Claims) for logins and that seems to be the cause of this issue. The give away is clearly in the error: “This method can only convert identity claims”.
Solution
Fortunately the solution turned out to be rather simple, it seems that SP1 does some additional checking when setting up the Cube Roles, as a result when users in the Project Server have issues then this error is caused.
A little more info can be seen in the ULS log:
09/02/2011 12:00:33.18 Microsoft.Office.Project.Server (0x17B0) 0x1A04 SharePoint Foundation Claims Authentication d01p Medium ConvertWindowsClaimToWindowsPrincipalName() encountered error: Some or all identity references could not be translated.
As it turns out a number of users in PWA have left the company and in this case as no AD-sync is used some of the accounts had been deleted from Active Directory but not updated in PWA server settings.
It seems also that accounts set as “inactive” also caused this error if they were in a group with the Global “View OLAP Cubes” permission.
The fix was to remove those user accounts from the PWA groups ‘Project Managers’, ‘Portfolio Managers’ and ‘Executives’ (and any others with the above permission).
Finally I just tested this in a non-Claims lab, and the problem doesn’t occur, in fact the cube log identifies and lists the invalid account then continues processing, so technically I would call this one a code defect.
Hope that helps someone else out there!
by Martin Laukkanen | Jul 16, 2011 | Exchange, Troubleshooting
Recently I worked with a large customer getting to the bottom of some issues experienced with Exchange Sync in Project Server 2010, specifically the issues originated due to the large multi-forest nature of the Active Directory environment in which the Project Server was deployed.
Symptoms
Exchange Sync for resources not working, little is logged in the ULS without verbose logging other than the following:
06/30/2011 12:25:49.04 Microsoft.Office.Project.Server (0x0E3C) 0x08C4 Project Server Queue 954k Medium PWA:http://pwa.something/PWA, ServiceApp:Project Service Application, User DOMAINServiceAcc, PSI: [QUEUE] Retry: 1 ExchangeSyncTasks Microsoft.Office.Project.Server.BusinessLayer.QueueMsg.ExchangeSyncTasks
To get to the bottom of what was happening Verbose logging on Project Server Exchange Tasks was required which showed far more detail which I will summaries here:
06/30/2011 12:25:48.00 Microsoft.Office.Project.Server (0x0E3C) 0x16D4 Project Server Exchange Sync fux2 Verbose -! Info: System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond xxx.xxx.xxx.xxx:443 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at … …
06/30/2011 12:25:48.00 Microsoft.Office.Project.Server (0x0E3C) 0x16D4 Project Server Exchange Sync fux2 Verbose =? Trying to Autodiscover using email at ‘https://autodiscover.companydomain.com/autodiscover/autodiscover.xml’
06/30/2011 12:25:48.04 Microsoft.Office.Project.Server (0x0E3C) 0x16D4 Project Server Exchange Sync fux2 Verbose -! Info: System.Net.WebException: The remote name could not be resolved: ‘autodiscover.companydomain.com’ at System.Net.HttpWebRequest.GetRequestStream … …
06/30/2011 12:25:48.04 Microsoft.Office.Project.Server (0x0E3C) 0x16D4 Project Server Exchange Sync 1zpd Verbose Error is: ExchangeSyncEWSUrlFailed. Details: Attributes: a6a779c4-a930-461f-a738-a3c78e8e826a . Standard Information: PSI Entry Point: Project User: DOMAINusername Correlation Id: a1e43a95-1a78-44a0-be1b-e8b3aa267074 PWA Site URL: SSP Name: Project Service Application PSError: ExchangeSyncEWSUrlFailed (40509)
06/30/2011 12:25:48.04 Microsoft.Office.Project.Server (0x0E3C) 0x16D4 Project Server Exchange Sync 9fbi Verbose Error is: ExchangeSyncGeneralProcessingFailure. Details: Attributes: a6a779c4-a930-461f-a738-a3c78e8e826a Microsoft.Office.Project.Server.BusinessLayer.Queue.
ExchangeSyncEmailAddressInvalidException: Could not find Exchange server for resource a6a779c4-a930-461f-a738-a3c78e8e826a at Microsoft.Office.Project.Server.BusinessLayer.Queue.
ProcessExchangeSyncMessage.ExecuteSync … …
06/30/2011 12:25:49.04 Microsoft.Office.Project.Server (0x0E3C) 0x0DD0 Project Server Exchange Sync fux2 Verbose ?? Starting SCP lookup for domainName=’companydomain.com’, root path=”
[cut out multiple variations of the above as Autodiscover tries in vain to find the account]
If you’ve read through that, you can see that Project Server is attempting to use the Exchange Autodiscover service to locate the users Exchange details, as per the Autodiscover protocol which very very basically is something like this:
- Look for an Autodiscover service on the host (then look on the same host without the autodiscover bit)
- If not found try an SCP (Service Connection Point) lookup in Active Directory to find the resources
This can fail in a multi-forest Active Directory environment if your Exchange Client Access Servers (CAS) are located in a different forest. As was the case with my customer.
Solution
This is actually a well understood problem in Exchange circles, and the full solution is well documented:
How to Configure the Autodiscover Service for Multiple Forests
However if like in my case you don’t have the time to get a significant change such as the above completed then an alternative is needed.
Workaround
Looking at the above autodiscover procedure an easy “workaround” (I call this one a ‘hack’) is clear;
- Add an entry to the HOSTS file on all Project Server application servers pointing to autodiscover.companyemaildomain.com which points to the actual autodiscover service running on the Exchange CAS.
However now you’ll see something like this in your Verbose ULS:
06/30/2011 12:40:04.17 Microsoft.Office.Project.Server (0x0E3C) 0x1930 Project Server Exchange Sync fux2 Verbose -! Info: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
This is because your Exchange CAS has something like as the Subject CN in its SSL certificate which would be expected, so what you need to do add a Subject Alternative Name to your certificate, see the following article on doing this:
Configure SSL Certificates to Use Multiple Client Access Server Host Names
Now you’re almost there, just one last thing! In order for the Exchange and Project Server to both authenticate these cross-forest users you need to make some changes on the service account on both forests by configuring the msExchMasterAccountSid property on the Exchange forest. See the following similar technet forum solution to achieve this:
EWS returns error "Failed to get valid Active Directory information for the calling account"
Done.
Hope that helps someone else out there!
by Martin Laukkanen | Jul 1, 2011 | SharePoint 2010, Troubleshooting
Had some time today to upgrade my lab to SP1, and thought it worth a quick post here about my experience.
For many people SP1 will be the first update applied to Project Server and SharePoint 2010, so with up to a year or more of production use it’s very possible that some features / solutions have been installed and removed which might cause some problems for the SP1 install.
In my case on my development lab this was most certainly the case with literally dozens of (often half developed) solutions in various states of deployment!
So in this case you may have the configuration Wizard fail after SP1 setup with a message like this:
Upgrade Timer job is exiting due to exception: Microsoft.SharePoint.Upgrade.SPUpgradeException: Upgrade completed with errors. Review the upgrade log file located in C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14LOGSUpgrade-20110701-160359-545.log. The number of errors and warnings is listed at the end of the upgrade log file.
Digging into the log mentioned reveals something like:
[ERROR] [7/1/2011 4:17:20 PM]: The feature with Id d67567a3-4946-412f-9428-1ca6061a5189 is referenced in the database [WSS_Content], but is not installed on the current farm. The missing feature may cause upgrade to fail.
(A very helpful and surprisingly accurate message)
The problem as you can see is a missing feature, however using the standard PowerShell get-SPFeature commands don’t reveal anything. This is due to the solution already being uninstalled (or perhaps never installed in the case of a migrated database). Fortunately there is a solution:
Thanks Phil, using the provided scripts I was quickly able to identify and remove the offending feature. Once done a rerun of the PSCONFIG wizard (in my case using the command line “PSCONFIG –cmd upgrade –inplace b2b”) completes without errors.
Hope that helps someone else out there.
