PROJECT SERVER 2010. NO SE PUEDEN GUARDAR RECURSOS EN PWA DESPUES DE INSTALAR LA ACTUALIZACION DE MARZO.
Hola,
Nos ha parecido relevante haceros llegar esta información que publicó Brian en el blog de Soporte de Project, donde nos avisa de un posible problema a la hora de guardar recursos en Project Server 2010, después de instalar la actualización de Marzo de 2015. El post original (en inglés) se puede encontrar en este enlace:
Y en él se nos indica lo siguiente:
“Gracias a Adrian y Lars por sacar a la luz esto en la sección de comentarios del post que hablaba del lanzamiento de la actualización de Marzo de 2010 para Project Server 2010. Debemos tener en cuenta que nos podemos encontrar con este problema si cargamos la actualización de Abril o Mayo de 2015, ya que no espera se pueda arreglar esto hasta la de Junio de 2015. Independientemente, la manera de arreglar esto es muy sencilla.
Un síntoma es que al editar un recurso y tratar de guardarlo, nos encontremos con un error desconocido. En los logs ULS podemos encontrar algo como esto:
Exception occurred in method Microsoft.Office.Project.Server.BusinessLayer.Project.ProjectQueueUpdatePDPProjectCF System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object 'MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs', database 'ProjectServer_Published_PWA', schema 'dbo'.
Esto es debido a la falta del permiso “ejecución” para el nuevo procedimiento almacenado que fue introducido en la actualización de Marzo que solventa el problema:
You cannot update a local custom field by using Project Server Interface (PSI) if the field is associated with a lookup table. Additionally, you may receive a "GeneralUnhandledException" exception.
El procedimiento almacenado en cuestión, como se deducía de mensaje de error que mostraba la excepción, es el llamado “MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs”, y el fallo más obvio es al tratar de guardar un recurso, ya que se usa para manejar la información de los campos personalizados. Sospechamos que puedan existir otras maneras de mostrarse el fallo (posiblemente el problema que comentaban Aaron y Christoph sobre la pérdida de valores de campos personalizados). No hemos tenido la oportunidad de confirmar esto, y no estamos familiarizados con este problema en particular.
Para estar seguros éste es el problema que tenemos, sospechamos que revisando las propiedades del procedimiento almacenado, y los permisos, debiéramos ver esto:
Cuando lo que realmente se debiera mostrar es esto otro:
Para resolver esto, podemos otorgar permisos de ejecución a ProjectServerRole, ejecutando lo siguiente en la base de datos Published:
GRANT EXECUTE ON dbo.MSP_ReadLocalAndEnterpriseLookupTableInfoByUIDs TO ProjectServerRole
GO
También debiéramos modificar el procedimiento almacenado, el cual no debiera contener el comando “GRANT”, pero que sí lo hace actualmente, debido a que el comando “GO” no aparecía antes del comando “GRANT” en el script de la base de datos que creaba el procedimiento almacenado. Para hacer esto, debemos pinchar con el botón derecho sobre el procedimiento almacenado en SQL Server Management Studio (debajo de Programación, en la base de datos de Published) y seleccionar Script Stored Procedure as \ Alter To, New Query Editor.
En el procedimiento almacenado podemos comentar la línea del “GRANT”, poniendo dos guiones (--) y dándole a Ejecutar a continuación. La línea mencionada se encuentra muy cerca del final:
Lo irónico del asunto es que, dependiendo de la configuración de permisos, esto se puede auto corregir, ya que fallará la primera vez que se ejecuta seguro, pero si la cuenta que lo ejecuta tiene los permisos adecuados para el comando “GRANT” y el procedimiento almacenado se haya
ejecutado bien la siguiente vez (esto le ha ocurrido a Brian). Si esto os ocurre también, es muy probable que tengais un sistema configurado con pocas cuentas de servicio, las cuales tienen muchos privilegios.
Es posible que queramos asegurarnos que hacemos esto mismo para todas las bases de datos de los sitios PWA que tengamos, pudiendo editarse el fichero addsps12.sql que tiene el “GO” original que faltaba, pero casi mejor dejar esto como está, ya que si se modifica este fichero otra vez, puede ocurrir que no se actualice luego correctamente si el fichero no se muestra como que tenga la versión adecuada.
Os pedimos disculpas por las inconveniencias que esto os haya podido causar.”
Felicitar a Brian por su estupendo trabajo, y esperamos os resulte de utilidad.
Saludos
Jorge Puig