The Statusing methods in the Project Server Interface (PSI) in Microsoft Project Server 2010 enable one user to read, submit, and update assignment and task status for another user, without resorting to impersonation. In the Project Server 2007 SDK, the How to: Generate ChangeXML for Statusing Updates article shows how to generate the changeXml parameter for the UpdateStatus method, validate the XML, and use the ReadStatus and SubmitStatus methods. The Project 2007 SDK download includes the complete Visual Studio 2005 solution for the ChangeXML utility. However, the ChangeXML utility could only update status for the current user. The ChangeXML utility  is now updated for Project Server 2010, in the attached ChangeXMLUtility.zip file. With it, you can generate the changeXml parameter and update status for the current user or for another user. To update status for another user, the utility uses the ReadStatusForResource and UpdateStatusForResource methods. In addition, the utility checks whether the current user has the global StatusBrokerPermission security permission, adds the ResID attribute to the changeXml parameter, and validates the XML against the updated ChangeList.xsd schema in Project Server 2010. For more information about the ChangeList.xsd schema, see Introduction to the ChangeList Schema and Statusing ChangeXML . Note : The ChangeXML utility is designed for use only on a test installation of Project Server 2010, as an example of a programming utility for statusing. It should not be used on a production installation. The updated ChangeXML utility also has several other changes. The previous version uses the ASMX interface, which was the only choice available for Project Server 2007. In the updated version, you can choose to proghrammatically initialize the WCF interface of the PSI by entering the Project Web App URL, or by using the WCF endpoint values in the app.config file. In the following screenshot, the login is automatic if you use the app.config value.         Note : To use the app.config file, change the URL to the value for your PWA instance, for each PSI service endpoint. In the main window, after you log on Project Server, choose Build Change XML .         You can choose to update the status of available assignments for the current user, or – if you have the StatusBrokerPermission – you can choose another user and update assignments for that user. In the following screenshot, the update is for another user. The Items available for update list shows the Project name : Task name : User name values for each item. You can choose to update assignment values or task values for that assignment. The Generate a Change dialog box shows different controls in the Update section, depending on what kind of update you choose. For example, if you choose to update an assignment custom field, you can choose the custom field and the lookup table value, if the custom field uses a lookup table.         When you choose Update XML , the tool generates the changeXml parameter value, as follows:         Following is the changeXml parameter value in the case shown, for updating the Health assignment custom field. Note that the XML value includes the ResID attribute for the Assn element. Late You can clear the Run Update check box to just validate the changeXml parameter. For example, manually change one of the elements, attributes, or values in the XML, and see if it still validates. Or, you can check Run Update to validate and run the change. When the change is completed, try opening the project in Project Professional. If you are the project manager, you are prompted to review the status change in PWA. If you accept the change in PWA, to see the change, open the project in Project Professional. For example, if you changed the Health assignment custom field, go the the Task Usage view, and then add the Health field to the view.         After you save and publish the project, you can also see the change in the Reporting database. For example, run the following query in SQL Server Management Studio for the RDB: SELECT TOP 1000 [AssignmentUID] , [ResourceUID] , [Health_T] FROM [ProjectServer_Reporting].[dbo].[MSP_EpmAssignment_UserView] Find the correct assignment and resource GUIDs in the Results pane: The ChangeXML utility is useful for creating and testing values of the changeXml parameter for the UpdateStatus method, where you can create and test changes for the current user and for other Project Server 2010 users.  —Jim Corbin

Thanks to a couple of my European support colleagues for sharing this one, which I know could also affect many of our customers world-wide if they are running servers that are not internet connected.  Great work by Jorge Puig Altozano from our Project support team in Madrid, and special thanks (and all the credit – according to Jorge) to Hector Calvarro for the SharePoint team – also in Madrid.  If Spanish is your preferred language then read on at http://blogs.technet.com/b/elfarodeprojectserver/archive/2012/02/22/project-server-2010-elevados-tiempos-de-respuesta-al-cargar-paginas-de-sitios-pwa.aspx and also Hector’s blog at http://blogs.technet.com/b/hablamoss/ .  Although we are just talking about PWA and SharePoint here – consideration also needs to be given to other 3rd Party assemblies that may be installed too – and this could affect the loading of PDPs. On to the English description – translation thanks to Jorge, with some additional input from Catalin Olteanu from one of our partners, UMT , as they also experienced the same slow downs. We had a Project Server 2010 server, with no Internet connection, that was returning high response times when we would try to load any PWA page – slow response was seen to be due specifically to the calls to SecurityCheckUserPagePermisison, and CheckUserProjectPermissions.  We observed the information n the SharePoint Developer Dashboard, and decided to take a look at the Certificates behavior. BriSmith note – I’m sure lots of analysis went into this decision by Hector – and for anyone interested in understanding more about the problem Catalin found the lookup for www.download.windowsupdate.com from a netmon trace, and the event viewer showing a 4102, and a couple of 4107 CAPI2 errors helped join the dots… We disabled the timeouts for the certificates verification in the SharePoint server On Windows Server , this component is on by default and , whenever an application is presented with a certificate that is not present in the trusted root store, it will attempt to contact Microsoft download servers to get the latest root chain. The SharePoint OOB certificates can induce this as they are stored in a particular repository (SharePoint- Under Certificate management -Local Computer), as opposed to the trusted root. The decision not to have SharePoint code creating and installing a root cert in the Trusted Root store was taken for security reasons (ex if an application could install a certificate into the TRC store might compromise the security of the system). Can this behavior be avoided? ( ie. bypass this check for subsequent validations). Supported workarounds:     Disable automatic update of root certificates on SharePoint Servers          • Launch gpedit.msc as admin on the box          • Go to Computer Configuration –> Windows Settings -> Security settings -> Public Key Policies -> Certificate Path validation settings          • In Network retrieval tab -> Define the policy and uncheck “Automatically update certs from Microsoft root cert program”          • Run gpupdate /force for policy to take effect immediately. Additionally , the cert management plan needs to be implemented as per below article: Manage Certificate Path Validation: http://technet.microsoft.com/en-us/library/cc731638(WS.10).aspx • It is not unusual for enterprises to disable auto-root update. If they opt to do it, they will have to manage distribution of third-party roots that they need in their enterprise via group policy. • The customer  will want to monitor new releases (KB931125) quarterly and update their trust as required. Implications of disabling : There should be no specific implications to SharePoint since we are using self-signed certs and manage them ourselves . The SharePoint certs do have an expiry and we do have a health rule that watches for that IIRC and will warn the admin to update/re-roll them.  The main aspect to think through is for “other” certs used on the box (like SSL certs, certs to trust download packages or for SAFER policy etc etc) which are issues from certs chained to those in the TRC store. But note there is nothing “new” about these issues with this setting; since the boxes in question cannot access the Internet … they actually “require”  more hands on. We also got rid of the verifications for Code Access Security and some other certificates (Certificates Revocation List and Authenticode signatures) doing the following: We have to edit this file: C:WindowsMicrosoft.NETFramework64v2.0.50727CONFIGmachine.config And add/change the value:             The explanation for this key: This element was introduced in the .NET Framework version 3.5 and applies only to that version. It has no effect in later versions of the .NET Framework. The common language runtime (CLR) tries to verify the Authenticode signature at load time to create Publisher evidence for the assembly. However, by default, most applications do not need Publisher evidence. Standard CAS policy does not rely on the PublisherMembershipCondition. You should avoid the unnecessary startup cost associated with verifying the publisher signature unless your application executes on a computer with custom CAS policy, or is intending to satisfy demands for PublisherIdentityPermission in a partial-trust environment. (Demands for identity permissions always succeed in a full-trust environment.) http://msdn.microsoft.com/en-us/library/bb629393(v=vs.90).aspx If we don’t use code signed by Authenticode, and work with CLR validations, we can work with the mentioned option. This is a more detailed explanation about this: A little background – CAS is feature in .NET that allows you to have more granular control over what code can execute in your process.  Basically there are 3 parts: 1.Evidence – Information that a module/code presents to the runtime.  This can be where the module was loaded from, the hash of the binary, strong name, and importantly for this case the Authenticode signature that identifies a modules publisher. 2.Permissions Set – Group of Permissions to give code (Access to File System, Access to AD, Access to Registry) 3.Code Group – The evidence is used to provide membership in a code group.  Permission Sets are granted to a code group. So when a module loads it presents a bunch of evidence to the CLR and the CLR validates it.  One type of evidence is the “publisher” of the module.  This evidence is validated by looking at the Authenticode signature which involves a Certificate.  When validating the Certificate the OS walks the chain of Certificates and tries to download the Certificate Revocation List from a server on the internet.  This is where the slowdown occurs. A lot of servers do not have access to make calls out to internet.  It is either explicitly blocked, the server might be on a secure network, or a proxy server might require credentials to gain access to the internet.  If the DNS/network returns quickly with a failure the OS check will move on but if the DNS/network is slow or does not respond at all to the request we have to timeout.  This can occur for multiple modules because we create this evidence for each module that is loaded.  However if we have looked for a CRL and failed we will not recheck.  However different certificates have different CRLs.  For instance a VeriSign Certificate may have one CRL URL but a Microsoft Certificate will have a different one. Since this probe can slow things down it is best to just avoid the probe if you do not need it.  For .NET the only reason you would need it is if you are setting Code Access Security based on the module Publisher.  Because this can cause potential slow downs and you do not need to occur this penalty you can just disable the generation of the Publisher Evidence when your module is loaded.  To disable this use the Application configuration.  Just set the enabled property to false and you will avoid all of this. Now for ASP.NET applications it was not immediately obvious how to do this but it turns out that
you cannot add this to an applications Web.Config but you can add it to the ASPNET.CONFIG file in the Framework directory.  For other applications just add the attribute to the APP.CONFIG file. More information here: Site slowness due to SharePoint STS Certificate CRL checking http://support.microsoft.com/kb/2625048/