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.)
Related
If I use an existing web application's content database for a new web application, Will that import all lists,sites and libraries into the new web application being created ?
Or
The normal backup and restore is required ?
A content database contains one or more site collections and all the websites, documents etc inside that database.
This means you can take a copy of a content database from your production environment and use it in your dev environment. However you will not be able to attach two copies of the same content database to a web application.
It may be possible to use it again for a second web application on the same SharePoint farm, but I strongly recommend against doing that in a production environment.
A content database does not store custom code and other customisations, these have to be installed before the restored sites will work correctly.
For more:
http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2010/11/02/sharepoint-2010-cookbook-migrate-a-sharepoint-2007-site-to-sharepoint-2010.aspx
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.
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.
Why do I need to create Multiple SSPs in MOSS?
My manager (sharepoint administrator) asked me to create another SSP which he wanted to use for TOP Management users. He didnt tell me what was the reason for it.
I was wondering what all scenarios we need to create Multiple SSPs. Any ideas?
Very vague question, please add more info!
And as a general answer, you don't need to, the concept is to share the services under the SSP between multiple web applications, what scenario do you have to need to create more than one?
Edit after question update:
An SSP host the services that will be used ( consumed ) by any associated Web applications. These services include :
Profiles
Audiences
Business Data Catalog Connections
Search and Indexing
Single Sign On
Excel Services
Usage Reporting
Source
So if your manager won't actually have something special on any of those services, I don't see a reason to do it. We had a customer once that needed the entire mysite and profiles customized, so we created a SSP just for that one web application.
Is it possible to create a user with permissions of both a local administrator and NETWORK SERVICE?
I've got a Sharepoint timer job which runs stsadm for which it needs local administrator permissions. On the other hand temer jobs are also used by other services which need NETWORK SERVICE permissions and those to sets of permissions only overlap, so I need a user with the "sum" of the permissions to run OWSTIMER under.
(I know that most of the operations you can perform with stsadm sharepoint administration API can be used, by in my case it is the operation which moves a site collection between content databases for which there seems to be no API equivalent).
I recommend always using domain accounts - SharePoint works best on servers connected to an Active Directory server. For production environments a best practice is using a least privilege account. I always create the following domain account dedicated to SharePoint services:
DOM\spservice
You do not need to grant any special privileges to this account as SharePoint will automatically do this for you when you specify the account during setup.
I can't help you with the user permissions (Lars hit the important points), but I wanted to share some information that may be of use.
You mentioned that you're trying to move site collections between content databases and haven't found an API the can be leveraged. Have you looked into SharePoint's Content Deployment API (also know as the PRIME API) to see if it can assist? The types of which I'm speaking are located in the Microsoft.SharePoint.Deployment namespace, and they provide you with mechanisms to export (via SPExport) site collections as CAB files and then import them (via SPImport).
SharePoint leverages types in this namespace for its own content deployment paths and jobs (in MOSS); it's also the API that is leveraged by the STSADM.EXE executable for export (STSADM.EXE -o export) and complementary import operations. For that matter, it's also used by SharePoint Designer for it's site "backup" and "restore" operations.
For an example of how this API can be leveraged, check out the SharePoint Content Deployment Wizard tool on CodePlex (http://www.codeplex.com/SPDeploymentWizard).
I hope this gives you a potential alternative to shelling out to a command line in your timer job!