BackUp and Restore WebApplication to Newly Created WebApplication - sharepoint

I need to create clone for particular web application on my MOSS server. I have taken full backup for my existing web application from
Central Administration > Operations > Perform a Backup. I just want to know how can I use this backup file and restore it on newly created web application.
Please note that my webapplication has more than 10 different site collections.
Thanks,
Ashish Chotalia

best way to do this is using the Backup/Restore feature in Sharepoint Designer as described on this site.
You can use Backup/Restore to move a site as well.
If you use Infopath forms on your site, carefully check where the forms are stored after moving the site. It can happen that they point to the "old" lists or databases.

Related

User has overriden a file on SharePoint, no versioning, possible to restore the file?

So the user seems to have overriden a file on a sharepoint list with no versioning. I don't know what SharePoint version it is, but it's definitely on prem (not online). A back-up was made yesterday, prior to the user overriding the file.
Is it possible to restore the file & restore everything back to normal from user admin/back-up? If yes, how?
As the first step enable versioning to the current library.
If there is a SQL backup create a separate site or web application and over write the database of the newly created web application with the existing backup.
The you can access the site using the newly created webapp , download the file and upload it to the original site.
Do the restoring of the database in a test environment as its not recommended to create so many web applications (More than 6).
References
https://technet.microsoft.com/en-us/library/ee748604.aspx
https://technet.microsoft.com/en-us/library/gg266384.aspx

How to add farm solution without using Visual Studio, PowerShell or Stsadm

I have a farm solution wsp which I want to add and deploy on a client's SharePoint farm.
Now I don't have remote access to this SharePoint machine but do have full admin rights to its central admin and related site collection, and can open the central admin and all sites through my machine.
Now as per my knowledge a farm solution is added to the SharePoint farm and not to the site collection, but I could not find any screen in central admin from which I can add my solution.
This is the case with both SharePoint 2010 and SharePoint 2013 servers.
What are the possibilities?
Basically, it sounds like you need to add and deploy a farm solution only using central admin? I don't think that is possible. If you look step one from MSDN
Adding: A solution package is added by a farm administrator to the farm's solution store, which is in the farm's configuration database. This is done either with the SharePoint Management Shell (or with the object model). It cannot be done in Central Administration.
You can't do this through web interface.
If you have full admin rights - you can use Remote PowerShell. But this require some setup on server. You can read this article about this: http://blog.incworx.com/blog/nik-brendlers-blog/administer-your-sharepoint-farm-remotely-with-powershell

Sharepoint 2007 - creation of another site collection within a intranet web application

What would be the best way/ steps to create a SHAREPOINT 2007 SITE which any one can browse through in our situation?
We already have a web application in our production which is used as a authoring site and a extended application for that site collection, were the public can access it without authentication.
Can I create another SITE COLLECTION under the current web application and then create a required web page in it?
Thanks
Jag
You can create many site collections per web application. Just go to the Central Administration console and under Sharepoint Site Management, (Under Application Management), click Create site collection. You will then be asked to select the web application under which you want to create it.
Note too that the url will appear something like webappname/sites/sitecollection
hope this helps,
sivilian

How to migrate the data between two SharePoint Farms?

I want to perform the data migration between two SharePoint farms located on the same active directory. I don't know on how to migrate the data from one SharePoint from to another new SharePoint Farm
Several ways of doing this:
1) Backup content database on source farm and restore in target farm, then attach to a web application.
2) Create (i.e. export) a content migration package on the source farm and import on the target farm
3) Set up a content deployment path between the source and target farms (probably not appropriate in this case)
All of these are documented extensively on Technet. If you have custom or third-party code you will need to deploy these to the target server also.
The fundamental processes will be like this:
Create a new web application in your new WSS server.
Follow the instructions in Move content databases between instances of SQL Server.
However you may not be able to perform all of the steps exactly as written if your previous server farm is not available. The main thing is that you get the most recent backup of the databases restored on your SQL Server, then follow these steps from the linked article:
In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.
On the Manage Content Databases page, click Add a content database.
On the Add Content Database page, type the exact name of the transferred content database, and then click OK.
Repeat steps 14 and 15 for each database you are adding. Be sure that you select the correct Web application from the Web Application menu for each database.
I don't know your farm topology but if you are sharing the same SQL Server used for the dead server farm, make sure that the dead farm is completely powered off. You don't want two different SharePoint farms accessing the same data (especially if one is in an inconsistent state).
If the old farm is alive and not in inconsistent state then you will be better off using a migration tool even if the versions of new and old are same.
The reason is that service packs, patches as well as order of their installation causes differences in SharePoint instances which can mess backup-recovery mechanism.
Migration is much more forgiving as it pre-assumes that differences exist between source and destination.
Several migration tools are available with Sharegate being my favourite.

Deploying a webpart which depends on a database store

Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)

Resources