I'm looking for a way to duplicate the content of a SharePoint 2010 server in order to work against it without taxing the main (production) server. I would need the backup server to update as needed, but I'm not looking for a failover solution. It looks like 2010 includes replication features for failover, but I can't tell if this is appropriate for my solution as well (simply not configuring the switchover feature). Can someone with SP 2010 experience tell me if this feature would work for my needs?
You could attach a restored backup of your production content database. See this MSDN documentation for more info: Attach or detach content databases (Sharepoint Server 2010).
There is also a GUI tool http://sushi.codeplex.com/ which should help you. You could backup production and restore to dev site whenever you needed to.
You could also use either stsadm.exe and the backup/restore option OR the powershell cmd backup/restore.
In addition, there is a built in interface in Central Admin to backup/restore sites. I've generally found either the command line or the SUSHI tool to be quicker and easier.
In most cases, the taxing work is on the sharepoint side, not the SQL side. You could attach another front end to the farm but reserve it for only your traffic. Otherwise you're looking at some form of backup/restore to copy everything to a 2nd duplicate farm.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
I'm not sure if this should be posted here or over superuser, but how does one go about mirroring a Sharepoint 2007 site? I have admin access, and the mirror doesn't need to be nice and pretty; it just needs to be presentable and readable. Also, I need all the shared docs to be copied as well.
We use to have WinHTTrack to mirror the Sharepoint, but that broke a few months ago due to some of our recent security changes. I tried the username#password:domain method but that resulted no luck.
It depends a little bit on how and where you want to mirror it.
If you have a separate SharePoint farm (even a single server - one tier - farm), you can rely on backup / restore, export / import or content deployment to have another copy up and running that will be a mirror of the existing one.
If you want an offline version, depends on what kind of content you need (collaboration stuff ?) you can use Microsoft Groove 2007 that offers an offline mode for some of the targeted data.
I've found this great tool that can mirror the SP site for cheap: http://www.metaproducts.com/OEPR.html
If WinHTTrack did satisfy you, why not just fix it?
There are solutions around the web to have WinHTTrack work with NTLM authentication: http://forum.httrack.com/readmsg/7513/index.html
However the download link seems to be broken (geocities..), but you could try to search for NTML proxy solutions and try to setup your own.
I'm in a machine that has already SharePoint installed, so when I started the SharePoint Central Administration to config, this message appear to me: "Can not connect to the database configuration."
How do I know which database is configured SharePoint?
Normally the Admin database is created using the naming convention SharePoint_AdminContent_{GUID}. However if there's more than one, you'll need to use SQL Management studo or other tool to look inside the DBs, look for a table called "DatabaseInformation" which will contain two items, look in the AlternateAccessMappingXML entry and look for the XML tage IncomingUrl, that should help you narrow it down.
Or just use the SQL profiler and watch for connections.
By default SharePoint will install the Database on the same machine as the web server, but you can ask whoever installed SharePoint on the machine.
Anyhow, most likely it's not relevant and something else is the problem, follow the resolution methods described here and you'll probably have it fixed.
I have a series of reports served by SSRS. They are great and the users like them.
That being the case, upper management wants to throw a wrench in the works and serve the reports from the Sharepoint server.
Is there a realtively painless way to let users access the reports from sharepoint? How would somebody go about doing such a thing? Or do I just need to bite the bullet and try to stop the madness?
I'm not sure which version of SSRS or Sharepoint you're using, but there have traditionally been both a Report Viewer and a Report Explorer web part shipped with Sharepoint in the RSWebParts.CAB file (at least since SQL Server 2005 SP2 I think). You can start there, but if you wanted quick and low-tech you could put in an IFRAME web part and point it to the Reports folder on your SSRS Server. Since you're using Sharepoint, that's also making the assumption that you're using Windows Authentication, so that wouldn't be an issue there.
Here's a link that might be of some use:
Viewing Reports with SharePoint 2.0 Web Parts
The most painless is going to be to run SSRS in Native mode, which it sounds like you're doing already, then install the SSRS web parts on your WSS/MOSS server.
You will have to manage security and report source control using some other methods besides sharepoint, however you don't have to deal with installing WSS/MOSS on your SSRS box and adding it to your SharePoint farm.
The more painful option is to run SSRS in Integrated mode. This allows you to use all the SharePoint document management stuff for your reports and share the same security setup however, the server configuration can be lengthy and difficult to setup.
http://msdn.microsoft.com/en-us/library/bb677365.aspx
Hope this helps!
Ben
I'm in the process of moving a complete sharepoint install to a different server.
Can anyone tell me if it's possible to just move the existing Shared Services Provider rather than starting from scratch?
All the best
You really need to move the SSP in concert with everything else in the farm. The two things to move are 1. databases and 2. the file system.
A .doc file for moving all of the SharePoint databases has been published here. Microsoft will soon have an updated procedure for this published on TechNet, according to the To The SharePoint blog.
Then to cover off any file system changes, I would set up a clean install of SharePoint (if you didn't need to already by following the document mentioned above) and do a file comparison between your source and destination SharePoint application servers. I usually use WinMerge as its free but Beyond Compare is also good. Also check any custom solutions are deployed on your destination server.
By ensuring your databases are moved correctly and all of your files are in place you should be OK. Make sure you test every custom component on your destination server before erasing the source databases and files (even better, archive the source).
Yes, create a new SSP and move the applications.
How to on migration of applications here
For moving the SSP to a new farm
Or try the Microsoft SharePoint Administration ToolKit v2.0
For another view of this