none
Convertto-SPProjectDatabase Fails with User does not have permission to perform this action RRS feed

  • Question

  • Hi,

    The Convertto-SPProjectDatabase cmdlet fails with "User does not have permission to perform this action". The ULS logs show that failure occurs after the Draft migration has completed successfully and the Published migration is beginning. It's attempting to exec sp_addlinkedserver, which the install account doesn't have SQL Server permissions to do. I don't understand why a linked server is required since all of the databases are on the same SQL Server. Does anyone know what is going on here?

    Thanks,

    Erik


    Erik RHS

    Tuesday, January 6, 2015 5:35 PM

Answers

All replies

  • After looking at the ULS logs a little closer, I can see that it was attempting to create a linked server using the machine name. I used a DNS alias for the database server when creating the farm and all content databases. I also passed this DNS alias as the Dbserver parameter to Convertto-SPProjectDatabase. Not sure why this is happening or what I can do to prevent it.

    Erik RHS

    Wednesday, January 7, 2015 1:05 AM
  • Hello Erik

    Not sure why process is setting up a linked-Server, but if it is then that is the process it is using. 

    Did you run the TEST-SPContentDabase and see if any issues were listed?

    Did you run the TEST-SPProjectDatabase to see if any issues were listed.

    Have you tried the migration using an account that is fully privilege with SQL Server?  If it fails, then we know it is not because it is lacking SQL permissions.

    Also, have you tried the process and capture what SQL is doing using the profiler?  

    Prior to the SharePoint 2013 upgrade, did you have Project Server 2010 at SP2?

    Cheers!


    Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCSD, MCSE+I, MCDBA
    Website http://www.WhartonComputer.com
    Blog http://MyProjectExpert.com contains my field notes and SQL queries

    Thursday, January 8, 2015 3:49 AM
    Moderator
  • Hi Michael,

    Thanks for the reply. Yes, the process works fine when the user has SA permissions in SQL Server. Problem is that in a large company, getting SA permissions to a SQL Server box requires some kind of justification. All of the MSFT documentation that I am aware of specifies that the install account needs the dbcreator and securityadmin roles. I opened a case with MSFT and am having the same discussion with them. I will definitely post back when I have a resolution.

    Cheers,


    Erik RHS

    Saturday, January 10, 2015 4:53 AM
  • This was my fault... specifically for not reading http://technet.microsoft.com/en-us/library/cc197607(v=office.15).aspx closely. In previous versions of Project Server, the install account only required the dbcreator and securityadmin roles. It now needs the sysadmin role.

    Erik RHS

    • Marked as answer by Erik RHS Friday, February 13, 2015 12:22 AM
    Thursday, January 15, 2015 8:55 PM