Restore Project server databases and instances to another farm

6 February, 2014 0

As I said in my previous post, today we will see how can we move project instances to another farm which including all your project server databases.

Before we delete PWA databases from sql server we need to accomplish some tasks in the order:

  • Delete/remove all the pwa instances from project server provisioning center (PWA service app)
  • Connect to sql server analysis services and delete the respective pwa instance cube db’s.
  • Go to timer service job definition and remove any jobs related starts with  PWA*
  • Verify back with powershell commands below listed if you still have any orphaned PWA instances or timer jobs and remove them.
  1.   Open the SharePoint management shell and run these commands.$serviceapp = get-spserviceapplication | ? {$_.TypeName –like “*Project*”}
    This will get the project server service application
    $pwainstances = $serviceapp.Sitecollection

    $pwainstances | ft name, id
    This will list all PWA instances referenced in the config DB

  2.  

    Repeat these steps for each PWA site to delete them individually

    $toberemoved = $pwainstances | ? {$_.Id –eq “a1a29814-983e-4cad-a730-9a80d40737f7”}
    Enter the instance ID from query results in the previous step
    $toberemoved
    This will confirm the instance you want to remove
    $toberemoved.Delete()
    This will delete the instance

We can now go forward and backup the pwa db’s and restore them to this farm.  follow steps to restore db’s

Now comeback to Project Service Application and create a new PWA instance and provide the same PWA instance name which exists in your other farm (eg: http://spserver-webapp/PWA-name ) so PWA-name should be same as restoring farm pwa-name – *important*. Then provide the database names while creating the pwa instance as you restored from source farm. Once the pwa instance is created we need to create the PWA root site. Note: do not backup and restore the root site db from source farm, rather create a new db and assign max site count to 1. Basically we are storing each PWA instance root site separately for each PWA site.

Post Update tasks after the PWA instance and root site are created:

  • Open the PWA instance site and go to server settings -> manage users and add the service account or your admin account to the list or users and administrators group, as the current db does not contain the destination farm service account it will hold the source farm farm account.PWA-1
  • Then open up the “Basic Project Plan” under workflow and project detail pages –> Enterprise project Types. Open the Basic project plan and add the project detail pages as below.
  •  pwa-2
  • Either disable notifications E-mail settings or modify them to suit this farm. This setting under operational policies –> Alerts and Reminders
  • Go to OLAP database management which you can find under Database Administration. Edit the existing one listed and change the database server and instance details, give it a couple of seconds and click “build Now” and watch the status there it self as it refreshes.

We should be good, if every thing went well. Also follow the below links for further troubleshooting.

http://social.technet.microsoft.com/Forums/sqlserver/en-US/61979d9a-59f5-49bf-b047-724f4c859a22/migrating-project-server-2010-to-new-farm

http://pwmather.wordpress.com/category/migration/

http://technet.microsoft.com/en-us/library/gg128952.aspx#section4

 

SharePoint Content databases move from one farm to another – data refresh process across farms

22 December, 2013 0

            Today we will see how we can get all the content (including Site Collections and Content Databases) from one SharePoint Farm to another farm. This also including content from Project Server Databases.

          While we are planning to upgrade SharePoint 2010 to 2013, we need to replicate the upgrade process in staging farm  to be as close to production farm. The main goal here is to move all the current content and from production farm to a staging farm where both the SharePoint farms share a similar architecture in terms of servers, service applications and web applications.

Note: project server db refresh process will follow in next post 🙂

The High level Plan:

  1. Gather all the web applications and their content databases.
  2. Get all the content databases from TST/Stagning env. where you want to detach all the databaess.
  3. Detach all the databases from the farm using a simple command or script (check below)
  4. Once verified all the databases have been detatched and remove them from DB servers.
  5. Backup and restore databases from PROD db server to this staging farm.(make sure the db owner is changed to farm service account)
  6. Mount the databases restored from prod and set the necessary max and warning site count.
  7. Restore any custom databases which are being used for any third party tools or custom solutions from PRD to Stage farm
  8. Clear all the SharePoint Timer cache.
  9. Reset all the search index data for all the search applications and once attached all the databases fire a full search.
  10. If you have blog cache implemented then you need to refresh the cache (delete and let it rebuild again)
  11. Restore “emailenabledlists” table from sharepoint_config database (what ever is the config db in prod ) to stage (optional: this isonly required if you need the email enabled lists and email details of the lists/doc. libraries/discussion forums you want to restore)
The remaining challenges for the staging farm to be identical was to migrate the managed metadata database from prd farm and 
Now lets see the basic PowerShell cmdlets to be executed for the above steps:
Web application – site collections and content databases can be gathered: (execute for each web application)
PowerShell shell:\>Get-spcontentdatabase  -webapplication http://webapplication | select name  > c:\webapplicationname-contentdatabase.txt
Note: In case if we use more than one SQL DB instances, we need to make sure content databases are restored in respective DB instances as per the farm architecture.
UnMount Databases – Simple PowerShell script – copy all your databases we captured in the above step to one file:
$dblist = get-content c:\stg-detatchdb.txt
foreach($db in $dblist)
{
      dismount-spcontentdatabase -identity $db -Confirm:$FALSE
}
Attached databases in Stg farm:
$dblist = get-content c:\stg-attachdb.txt
foreach($db in $dblist)
{
    
Mount-SPContentDatabase -WebApplication http://webappname -Name $db -Confirm:$FALSE -DatabaseServer “dbsrever\instance” -MaxSiteCount -WarningSiteCount
# your can use the below command to again set the max and warning site count
#Set-SPContentDatabase -identity $db -Confirm:$FALSE -MaxSiteCount 1 -WarningSiteCount 0
}
CLEAR SHAREPOINT TIMER CACHE:
You can clear the timer cache either manually on each server in the following way 
http://blogs.msdn.com/b/josrod/archive/2007/12/12/clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx
Either you can clear the cache using a simple script:
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$servers = get–spserver | ? { $_.Role –eq “Application” }
$configDb = Get-SPDatabase | ? {$_.TypeName -eq “Configuration Database”}
$guid = $configDb.Id
foreach($spserv in $servers)
{
set-service -computername $spserv -Name sptimerv4 -status stopped
sleep 5
Remove-Item “\\$spserv\c$\ProgramData\Microsoft\SharePoint\Config\$guid\*.xml”
Set-Content “\\$spserv\c$\ProgramData\Microsoft\SharePoint\Config\$guid\cache.ini” “1”
sleep 5
set-service -computername $spserv -Name sptimerv4 -status Running
}
sleep 300
DISABLE BLOB CACHE SCRIPT:

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$WebAppServices=Get-SPWebApplication
foreach($webApp in $WebAppServices)
{  
     Write-Host $webApp
     Disable-SPBlobCache($webApp);
}
Remove-PsSnapin Microsoft.SharePoint.PowerShell
This completes the content db restore from one farm to another, I will write how to restore project server db refresh in next post.
Do write me back on your opinions and if we can improve on this process and include any missing pieces.

Required Permissions in SharePoint Farm for executing PowerShell scripts

1 December, 2013 0

Before you execute any of the SharePoint Cmdlet you must be sure that you have necessary permissions to execute in the farm. Also you must have access to local WSS_ADMIN_WPG group where you are executing the cmdlet. Also you must be member of the SharePoint_Shell_Access SQL role within the databases your cmdlet calls in to interact with. Some commands also require you to be a member of the local administrator and farm administrator grooups. For ex. to create a web application, you must be a local administrator and farm administrator.

In Regards to adding users to the WSS_ADMIN_WPG group and SharePoint_Shell_Access SQL role, you must not be adding users directly to these groups rather you should use Add_SpShellAdmin cmdlet. This cmdlets accepts optional database name as parameter. If you do not pass this parameter it will add the user to the SharePoint_Shell_Access SQL role in the SharePoint configuration database only.

Above third line of code, it will add Add_SPShellAdmin SQL role in all the SharePoint databases including configuration database. Also you must be farm administrator and you must have securityadmin SQL role in order to execute this cmdlet.

  • Use Remove-SPShellAdmin to reveke access

When it comes to removing access you should use the above command to remove permissions, however it will not remove access to the user from WSS_ADMIN_WPG group on any server. You should remove this access manually. I recommend you should create “SharePoint Shell Access” AD group or groups if you want more fine grained control and grant these group Add-SPShellAdmin access there by avoiding the case users retaining the rights, where they shouldn’t.

When we get to the point where we need to execute scripts you may have to set execution policy  to allow scripts to run. You could do this using Set-ExecutionPolicy  by passing the execution policy.

  • Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
While setting policy for production farms I recommend using policy scope to Process so it does not persist other PowerShell instances.

Can you move a single large site collection into multiple content databases?

1 December, 2013 0

Although single content databases of upto 200GB is possible in Sharepoint 2010, administering and managing such a db would be a nightmare. What would you suggest for options in a case where there is one site collection and one corresponding content database. Can you have more than one content db for that one site collection? Can you expand the table to be hosted on other sql servers/machines? Does RBS help?
Expert Comments:
Officially there is support up to 4TBs with optimization, but realistically that is difficult to support and should only be used in extreme exceptions. Technically there were no real changes made to support the additional sizes, it was just an update to guidance. I still try and work with my customers to maintain databases no larger than 75-100GBs unless absolutely necessary. I do have customers with multi-terabyte farms.
A single site collection can only use 1 Content DB. It is possible though to create solutions that use a single site collection that interacts with multiple site collections for content storage. Its transparent to the users, but splits the content across multiple sites, multiple content dbs.
RBS can also help. The big advantage there is it reduces storage within the content db. I’m not as sold on RBS though in most scenarios. There are benefits, but there are also costs and added complexity. If you have an extremely large data source that MUST be in a single site collection and content cannot be archived, then this may be a good solution.
As for multiple SQL servers, you can leverage multiple SQL servers for a single farm, but my understanding is that a single database and all supporting data/log files must be part of the same instance. Using multiple data files on separate disk partitions though is part of the guidance to increase performance on those content dbs above 200GB.
© Copyright 2018, SharePointChips All Rights Reserved