Freigeben über

Real world problems upgrading to Project Server 2013

  • Artikel

I recently helped a customer upgrade from Project Server 2010 to Project Server 2013. In the course of preparing, testing, and then running the actual upgrade, we ran into 7 problems that affected the upgrade. I want to share these so you can include them in your upgrade planning. These problems can be planned for in any version to version upgrade for Project Server.

 

  1. Minimum hardware specifications

    1. Production VMs were not set up with correct min hard drive specs on the system drive. The group responsible for providing the VMs operates under a “You have minimum specs? Prove it by crashing your production application under load.” The proof of the need comes from the minimum hardware and software requirements KB article for Project Server 2013. There is no dispute what the minimums are and I always recommend you go better than the minimum. Because of budget and personnel restraints, load testing was not possible for this customer.

    2. What can you? Hire an architect to help you determine what your requirements are for Project Server and your reporting needs and then implement the architecture they recommend.  Set up a test lab and run performance tests. If you can't hire an architect, present the minimum hardware and software requirements KB article to your supplier and demand nothing less; in fact, demand more. Load testing will help you make your case for more.

  2. Log on locally for setup and farmadmin accounts

    1. The Project Server 2013 service accounts were configured in AD months ago in preparation for the upgrade. In the middle of configuring the farm, Security configured the group policy for all service accounts company-wide to prevent them from logging on locally. They did this without informing anyone.  This change had the effect of stopping the production installation/configuration in its tracks for three days while we held meetings with SharePoint PFEs to explain the need to Security. We managed to convince Security that we needed the log on locally rights until the farm was configured and then after that, we only need it to install updates then run the configuration wizard.

    2. What can you? Make Security aware that your setup and farmadmin service accounts will need log on locally rights to the production servers until the configuration of Project Server is complete and then again every time you install updates and run the configuration wizard.

  3. Default database location on SQL

    1. The production SQL Server had the default database locations configured to send DBs to C drive (C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\). The customer SQL Server team has no standard configuration defined and won’t set up the SQL Server according to a standard, predefined document where the database files are sent to a non-system drive. We had to make the change ourselves during a quick review of the server’s settings. In our case, the SQL Server is virtual but the data and log drives are on a SAN.

    2. What can you? Reconcile the SQL Server standard implementation at your company with where you need the databases to be and make the appropriate change to the default database locations before you get started installing and configuring SharePoint and Project Server.

  4. Misconfigured NICs

    1. The NICs were misconfigured on SQL Server which created very slow copy of databases. My contact had to pull in an internal resource to resolve this issue after attempting to copy production database backups to a share on the SQL Server. The copy started normally but became progressively slower until it was at a standstill.

    2. What can you do? Run a test copy of all the project server and content databases to determine how long the activity will take. If you notice degradation while the copy takes place, you may have a misconfigured NIC.

  5. Internet access for servers

    1. When my contact was ready to configure SQL Reporting Services, it wasn’t possible because when she needed to download prerequisites, the server was on a VLAN that can’t connect to the internet. We had to wait for the VM team to move the VM to a VLAN that could.

    2. What can you do? Ensure that your servers can access the internet ahead of time.

  6. WFEs act as “App servers”.

    1. There was a change in how Project Server handles timesheets in 2013 where the WFEs handle that workload. This means the WFEs act as “application” servers and must be allowed to connect to the SQL Server through its firewall. In the case of this customer, we had to request the WFEs be moved to the App server VLAN and firewall ports be opened on SQL so those machines could access SQL. This happened in TEST and again in PROD; it was frustrating to go through that a second time when we installed production.

    2. What can you do? Ensure the firewall ports are open so the WFEs can connect to the SQL Server just like the app servers can in all environments.

  7. Planned maintenance

    1. During the actual upgrade weekend, so many planned maintenance changes were happening on the VM host hosting the SQL Server that the host server actually crashed. This occurred 6 hours into a 25 hour content database upgrade and pushed our schedule out considerably. All the changes taking place that weekend were approved by the change control board; they just happened to be scheduled at the roughly the same time and the system was overwhelmed.

    2. What can you do? It’s worth checking into what changes are planned on your production machines and production host servers before your upgrade to ensure you will have a stable environment for the actual upgrade.

 

Originally posted at https://blogs.technet.com/b/brookswhite.