Attaching specific W3WP Worker Process during debugging in sharepoint

While debugging your custom code in the SharePoint instead of attaching all worker processes(w3wp.exe) this is the command to attach/identify only the current application specific w3wp process

Command to get the correct w3wp process

C:\wondows\System32\inetsrv\appcmd list wp

 

Here I have written my custom code on Sharepoint-1122 site and debugging the same. So the processor which attached to this application  is 4736(see above fig).

So attach only one process which is associated (like below) instead all

or You can directly get process id in IIS

To get list of running  worker process, Open IIS Manager ( Run > Inetmgr ), Select root level from left site navigation tree and from “Features View Panel” select “Worker Processes”

Click on the “Worker Processes” to get details of all worker process which are currently running as shown in below.

So from the above list of worker processes you can get the details of Application Pool Name, Process ID, state of worker processes along with CPU uses and memory uses.

Read More

Sharepoint Site collection backup/restore vs. site export/import with focus on running workflows, version history and auditing

Custom SharePoint solutions usually contain custom lists with custom event receivers, custom workflows, maintain version history, use auditing etc. For a site with lists that have those customization it’s important to make sure that the backup/restore process will not lose any of the running workflows, workflow tasks and their status, items version history (major and minor versions), registered audit events etc.
Regarding audit events, in fact they are saved in Audit table in the content database and site backup/restore or export/import will not affect that table but can make other changes(for example new site GUID) which will result in invalid rows in that table (one of the columns is Site ID (GUID)).
Database attach is always the best way to avoid any problems of this kind but in some cases for various reasons very frequent backup of the content database is not preferred and backup of a single site collection (SPSite) or single site (SPWeb) is required. Another reason for testing site export/import is that I’ve seen administrators using export/import for migration to another location and as a more frequently running backup plan and I was asked is it safe to do that for custom solution.

Test case:

I tested site collection backup/restore and site export/import in SharePoint 2010 (I've seen the same behaviour in SharePoint 2013 because I think there are no changes in that part but its not fully tested for 2013 as for 2010). In the site there was a document library with versioning (major and minor) enabled, auditing was enabled and there were custom workflows associated with the list. In the time of back up there were documents in minor and major version. Also some of the documents had workflows in running state. After the backup some versions from items versions history were deleted, running workflows were completed and workflows on other items were started. Also some of the documents were deleted and new documents created. After that the restore/import was performed and the restored/imported site was compared with the original state (state when the site was backed up/exported). Import of the exported site was tested by importing on the same location and also importing on another sub site.
Below are the commands for backup/restore and export/import and the results after restore/import. The focus is on running workflows, version history and registered auditing events.

Site collection backup

PowerShell command to backup a site collection

Backup-SPSite -Identity "site collection url" -Path "backup file path"

More information for Backup-SPSite: http://technet.microsoft.com/en-us/library/ff607901.aspx

Site collection restore

PowerShell command to restore a site collection

1	Restore-SPSite -Identity "site collection url" -Path "backup file path"

More information for Restore-SPSite: http://technet.microsoft.com/en-us/library/ff607788.aspx

Restore results:

The results are the same when restoring on the same location or another location, in the same web application or another web application.
Results:
-          The restored site collection has new site ID (GUID).
-          All items versions and workflows are restored successfully.
-          Audit events are lost. This happens because of the new site ID (GUID). This can be fixed by updating Audit table in the content database. If the site collection is restored in the same location or another location that uses the same content database then rows in Audit table should be updated by writing the new Site ID in the rows that have the old Site ID. If the restore is done on another location that uses another content database then new rows must be created in the Audit table in the new content database by reading the old audit events from the Audit table in the old content database.

Site Export

PowerShell command to export SPWeb:

1	Export-SPWeb [-Identity] "site url or GUID" -Path "backup file path"

More information for Export-SPWeb: http://technet.microsoft.com/en-us/library/ff607895.aspx
Important: Export-SPWeb does not export the running workflows.

Site import

Powershell command to import SPWeb:

1	Import-SPWeb [-Identity] "site url or GUID" -Path "backup file path"

More information for Import-SPWeb: http://technet.microsoft.com/en-us/library/ff607613.aspx

Import in the same location

If there are event receivers running custom code in the lists it’s recommended to remove all of them before import to avoid any failure caused by the event receiver logic. Depending on the logic of the event receivers import may completely fail or the imported web may have wrong items version history and other problems. After import event receivers can be added back. For removing/adding event receivers with PowerShell check one of my older posts Add, Modify or Delete List Event Receivers with PowerShell

Import results:

-          Import operation does not import the workflows (as expected, because they don’t get exported with Export-SPWeb).
-          Import does not affect the currently running workflows but import of the document versions fails for those documents with running workflow.
-          Versions are correctly imported only for document with no workflows in running state when importing.
-          Audit events are not affected by the import, so all events are retained including those registered between export and import

Import in another sub site

The following must be done before importing the exported site:
-          Create new site using the same template and same language as the exported site
-          As explained above, removing event receiver is strongly recommended

Import results:

-          All running workflows are lost
-          All custom site properties and custom item properties are lost (properties in SPWeb.Properties and SPItem.Properties hashtables)
-          All workflow associations are lost
-          Document versions are imported successfully
-          Audit events are lost
-          Workflow tasks are lost

Conclusion:

Database attach of a backed up content database is superior for custom SharePoint solutions that contain custom workflows, custom web and item properties, custom event receivers, version history etc. To avoid big content database and long backup times its better the custom solutions to be installed in a site collection that has its own content database instead of sharing one content database with other site collections. That way backup/restore space and time will stay in normal and manageable boundaries. In that case you can stick to database backup as the best backup/restore plan for highly customized and big SharePoint solution.
Site collection backup/restore is better than SPWeb export/import but not as trouble free as database backup/restore plan. The problems are caused by the new Site ID (GUID) generated. That causes lose of audit events, or more precisely additional work to correct the Audit table after the restore.
Site export/import is almost useless for custom solutions that contain custom workflows, event receivers, custom web and item properties, custom event receivers, version history etc. It has problems even if it’s used for simple sites that use only SharePoint out of the box functionality if it has lists with workflows and versioning enabled.

Read More

Import and Export Sites on SharePoint 2010 Using PowerShell

This article will show you how to import / export operation of a particular SharePoint site using Power Shell

1. On the Start menu, click All Programs.

2. Click Microsoft SharePoint 2010 Products.

3. Click SharePoint 2010 Management Shell.

4. At the Windows Power Shell command prompt type the following command:

5. You will get a Power shell command prompt like below

6. In SharePoint 2010, Power Shell command Export-SPWeb is used to export the site

7. Please see the screen shot for the Power Shell command

8. Export-SPWeb -Identity http:\\ServerName:port\Site -Path c:\\backup\Exportback.dat

9. The NoFileCompression parameter lets you specify that no file compression is performed during the export process. Using this parameter can lower resource usage up to 30% during the export process. Using this parameter will result in a backup folder being created instead of a compressed file. If you use the NoFileCompression parameter in the Export-SPWeb command, you must also use it when you import the content by using the Import-SPWeb command.

10. To import to a site you have to use Import-SPWeb command

11. The complete command is

12. Import-SPWeb -Identity http:\\ServerName:port\Site -Path c:\\backup\Exportback.dat -Force

13. I have used -force to over write the existing site in my destination

Read More