Differences between stsadm export and backup operations

 

It's not obvious to understand key differences between a backup and an export. Although they both are designed to reach the same goal, backup data, they work completely differently.

Stsadm –o backup/restore

With the URL and filename parameters, it allows you to backup either a site collection or web application. You can basically consider the file generated more or less as a SQL dump of (a part of) your content database. It keeps every GUIDs except one (and the most important): when you restore the file, it generates a new GUID for the site collections. This was done on purpose because Sites table of configuration database uses SiteID as primary key. This is very important because it allows you to restore the backup in the same farm in which you did the backup. You can even restore the same backup several times in the same farm, but you must always restore in a different content database, because all others GUIDs remain unchanged.

This operation is probably more designed for SharePoint administrators that want to backup data. Because it does not do anything else than dumping the SQL content database, administrators can be sure no data will be changed, transformed or lost.

Stsadm –o export/import

This is the only standard operation that allows you to store a sub site (a SPWeb), but it can also export a site collection or an entire web application. It exports the data using object model, and generates a new GUID for every objects such as sites, sub sites, lists and items.

Another difference is that an import does not involve losing existing data. You can restore a site in an existing site, the behavior with existing data is defined with the parameter updateversions in import operation.

A major drawback of this operation is that it does not copy any information related to workflows. If import creates new lists and a workflow was associated to them, you must recreate it manually. Additionally, it does not copy workflow history and tasks lists.

Contrary to the backup operation, it does not matter in which content database you run import operation, and you can restore a top site as a subsite, and reciprocally.

This operation is probably more designed for people that want to merge content of sites, and finely choose how to handle identical data between source and target. Very important, do not forget to use includeusersecurity parameter in both export and import if you wish to preserve information relative to permissions and other properties such as documents authors. Now let me boil down this more a precise tablular manner….!!remember this used to fetch more marks…..school day… hmmm…  

Backup/Resotre	Import/Export
1. Can back up top-level websites (Site Collections), an individual database, a Web application, or an entire farm. 2. There is no Default File Extension for back up files, however, I use “.bak”, 3. Supports "Full" and "Differential" back up. If "overwrite" option is selected while restoring it overwrites entire SiteCollection 4. Supports UNC path to save/restore backup files. 5. Backup of Site Collection can be tracked by stsadm -o backuphistory operation	1. Like Smigrate.exe utility in SPS 2003, you can migrate sites, subsites and Site Collection. 2. Default file Extension (if not mentioned) ".cmp" 3. Provides "versions" option to control migrate/overwrite files in site 4. Backup files should be copied to server 5. Sites/SiteCollections would not track export/Import history
Syntax	Syntax
For site collection backup stsadm -o backup -url <URL name> -filename <file name> [-overwrite] For catastrophic backup stsadm -o backup    -directory <UNC path or local drive>    -backupmethod <full or differential>    [-item] <created path from tree>    [-percentage] <integer between 1 and 100>    [-backupthreads] <integer between 1 and 10>    [-showtree]    [-quiet]	stsadm -o export    -url <URL name>    -filename <export file name>    [-overwrite]    [-includeusersecurity]    [-haltonwarning]    [-haltonfatalerror]    [-nologfile]    [-versions] <1-4>    [-cabsize] <integer value>    [-nofilecompression]    [-quiet]
For site collection restore stsadm -o restore    -url <URL name>    -filename <file name>    [-hostheaderwebapplicationurl] <Web application URL>    [-overwrite] For catastrophic restore stsadm -o restore    -directory <UNC path>    -restoremethod <overwrite or new>    [-backupid] <GUID from backuphistory, see stsadm -help backuphistory>    [-item] <created path from tree>    [-percentage] <integer between 1 and 100>    [-showtree]    [-suppressprompt]    [-username] <user name>    [-password] <password>    [-newdatabaseserver] <new database server name>    [-preservechangelog]    [-quiet]	stsadm -o import    -url <URL name>    -filename <import file name>    [-includeusersecurity]    [-haltonwarning]    [-haltonfatalerror]    [-nologfile]    [-updateversions] <1-3>    [-nofilecompression]    [-quiet]

To recapitulate -

It queries the site using the object model and stores everything the site had that was exposed using the front end UI, into the given file. By default, you might miss older versions of files in a document library that has versioning turned on. You can however specify command line parameters to these commands to influence further control on how older versions are backed up. Also, this approach is quite arduous for a farm with a number of sites. Most of all, stsadm can error out at times, and the error can show up on command line, or even worse, the command line may tell you that it worked, but an error may show up in a log file somewhere.

If this helps...... then please share......

HaPpY CoDiNg... (Aurum)

Deploy Solution v/s Upgrade Solution

STSADM – usage.

SharePoint developers/Administrators often come across a scenario where they have to decide between "deploysolution" and "upgradesolution". Following explanation will help you to decide.When you are deploying a solution for the first time you will use "deploysolution" command.
stsadm –o addsolution
stsadm –o deploysolution

When you are upgrading an existing solution in that case you can use either "deploysolution" or "upgradesolution" command.
If you go for "deploysolution" in case of already deployed solution, in that case you will have to perform following operations.
stsadm –o retractsolution
stsadm –o deletesolution
stsadm –o addsolution
stsadm –o deploysolution

In case of "upgradesolution" operation you need to fire only one command.

stsadm –o upgradesolution

Retract operation will remove the existing files and "deploysolution" will copy the files once again on the front end web servers. If you opt for "upgradesolution" this operation will also perform the same actions, removing and recopying the files.
 

So what's the difference between both the operations?

• "deploysolution" lets you rename the solution file. If you rename the solution file or change the GUID, "upgradesolution" operation will fail with an error stating that a solution with name or GUID does not exists in solution store.

• When you deploy a solution and then associated features are also installed but that's not the case with "upgradesolution" operation. If you uninstall the features and then upgrade the solution, it will not install the features. But if you deploy the solution it will install the features again.

I hope this post gave you clear understanding of "deploysolution" and "upgradesolution" operations.

If this helps...... then please share......

HaPpY CoDiNg... (Aurum)

Opening Doc Files in Browser from SharePoint Document Library – SP2007 Troubleshooting

Opening Doc Files in Browser from SharePoint Document Library

When you click on a file in a SharePoint document library, it launches the file. Most often you'll be prompted as to what you want to do with the file (Open, Save, etc.). In some cases (like Office documents) it will open the file but the program that is doing the client side work on it, renders it in the browser. How many times have you clicked on a Word document and have it launch in the browser so you're looking at IE with an embedded Word control rendering your document. Half the time the user doesn't know what happened and when they close the browser the site is gone when really they wanted to hit the Back button to get back to their doclib. How frustrating!!!!!.

Unfortunately the answer isn't an easy one, at least if you have a large deployment of users you need this to happen with. It involves setting up a property with the associated file. The setting is in the web browser, not SharePoint. The technique varies based on different environments (version of browser, version of OS, version of Office) so there's no golden rule but the default is generally to browse in the same window (at least it has been for me on all the setups I've seen) so it will open up inside of the IE when you're accessing it through your browser. This has the effect of embedding the Microsoft Word control in the browser and hence the problem. Thus, I would share what steps I followed in reconfiguring the file association:

1. Go to Windows Explorer (not Internet Explorer) (or My Computer)
2. Under the Tools menu choose Folder Options
3. Click on the File Types tab
4. Find the file extension you want to modify (say DOC for Microsoft Word Document)
5. Click on the Advanced Button
6. In the Edit File Type deselect "Browse in same window" for the Edit or Open actions (or all of them if you prefer)

Here's a screen shot of what you should see:

This will force it to launch a new (Word) window no matter where the source of the document comes from (say a doclib in a browser). I'm pretty sure there's a blog out on this that someone wrote but can't find it so hence this posting (feel free to link to it in the comments if someone knows of one).

If this helps...... then please share......

HaPpY CoDiNg... (Aurum)

Adding JavaScript in Content Editor Web Part

JavaScript has always been a good mechanism for client side scripting and manipulation. In SharePoint also we can extensively use JavaScript. One of the easy ways to use JavaScript out of the box is to associate the script directly inside the Content Editor Web Part. I will show you very briefly how we accomplish this. We will take a simple example of the "hello world".

Modify the CEWP, the CEWP has two edit options:
- Rich Text Editor: as it says, allows you to add formatted text.
- Source Editor: this is a more powerful option, allowing you to add html, scripts or styles.

Go to the source editor and copy paste the following JavaScript.

<span><div><input type="button" id="btnJS" name="Click" value="Click" onclick="javascript:TestJavaScript(this);" /></div> <div><script language="JavaScript" type="text/javascript"> _spBodyOnLoadFunctionNames.push("TestJavaScript"); function TestJavaScript(id) { if (id != null) { //alert(id); NestedMethod(); } function NestedMethod() { alert("Your Code goes here!!!"); } } </script></div> </span>

Save it and see the page...... Viola.... behaves like a custom built web part.

A trick to edit Web Part pages
On some pages, the edit option is not available or is grayed out. This is for example the case for the edit form of a list. The workaround here is to append the "?ToolPaneView=2" in querystring to your URL, which will switch your page to edit mode. Note that it seems to be unsupported by Microsoft, though I haven't read an official confirmation.

For example, if you want to edit:
http://ThisServer.com/sites/ThisSite/Lists/ThisList/editform.aspx
Enter:
http://ThisServer.com/sites/ThisSite/Lists/ThisList/editform.aspx?ToolPaneView=2

If you have a more elegant solution – please post a comment… I'll be happy to hear.

Share this............

HaPpY CoDiNg... (Aurum)