The Modern Workplace Hub: SharePoint, Power Platform & AI with Copilot

If  you are moving your site from Testing(Staging) to Production, site backup and restore (using STSADM command line tool)  is the way to go. Other ways include SQL Server, Sharepoint Designer, DPM etc. However, site backup and restore using STSADM is probably the easiest and fastest one. Backup the site using the following STSADM Command: Stsadm –o backup –url  http://<server name>:<port > -filename <path\name to be used for the backup file> Example: Stsadm –o backup –url  http://pravahaminfo: 4545–filename "e:\backup4545.bak" After the backup has been completed, “ Operation Completed Successfully ” message should be displayed. Create a new Web Application for restoring the site: Go to Central Administration -> Application Management -> under SharePoint Web Application Management -> click Create or Extend Web Application . Fill in the required information, click Ok and wait until the progress continues. Once ...

The major problem will be faced by the sharepoint developers/administrators starts when they complete the customization and move all their work to the Production Server. T he approach what we take for ASP.NET applications will not work out for sharepoint sites because all the page contents and configurations are stored in the database. So every developer will be thinking that there needs to be deployment project like MSI to easily deploy the sharepoint sites in the different machine other than the machine/server where we have developed. Microsoft has provided a command line tool to migrate all your works to another machine which is called as SMIGRATE.exe. This tool is available in your server (Which you have installed SPS and WSS) under the path.. Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin either in C drive are D drive ( Where you have installed the SPS and WSS ). Y ou can use this tool to backup and restore . To use this tool you must be a site admi...

Question: I have created a workflow for the document library using SharePoint designer, how should I move it to production server? Answer: Use a migration tool like DocAve, Metalogix, Quest, etc. If you don't have a tool, then you have to do a manual copy/edit like this: Create a new workflow on the Production site with the same name.  Be sure to add a fake condition and one fake activity.  This will generate the standard workflow files Copy the XOML and RULES files from your workflow in Dev (open the folder in SPD2010 and copy these specific files) Paste those files into the workflow folder you created in step 1 Open the workflow again in Prod, and click through all the steps to reassociate each data point (simply click on the item, and it will re-associate) If you have any lookups like "Update List Item," then you'll need to manually edit the XOML file in SPD or Notepad so that you can find/replace the GUID of the associated lis...

In our development world, especially with Visual Studio 2010 and SharePoint 2010, we have it very easy for deploying our solutions to SharePoint. As long as we have SharePoint installed on the same box as Visual Studio, we just right click the solution and deploy. Moving into the real world though, you’ll quickly find that having Visual Studio 2010 on a production or staging environment is not always there. Somehow we have to get our project from source code, to an assembly, and then to SharePoint. You may have asked: How do I deploy a SharePoint 2010 Solution or WSP file? How do I create my SharePoint 2010 WSP file? Where is my SharePoint 2010 WSP file? Let’s jump right in and answer those questions… Assumptions You have a Visual Studio 2010 SharePoint project set up and ready to go. The project compiles. Are able to use powershell. If you’re looking for a great starter project for SharePoint, why not try your hand at   Creating a custom Web Part ? Generating WSP: The firs...

Even though BCS is great and can do wonders when you want SharePoint 2010 to interact with your external systems or other LOB applications, it has its own limitations . Understanding these limitations will help you build good BCS solutions. Below are some/all of the BCS/External Lists limitations: Workflows cannot be associated with external lists However, you can use the external data columns and manipulate the external lists in a workflow. No RSS feed support for external lists. No REST based access for external lists The http://site/_vti_bin/ListData.svc does not support external lists LINQ to SharePoint spmetal.exe does not support external lists Cannot configure alerts for external lists Cannot export external list items to Excel (Export to Excel feature) Item-Level permissions is not available for external lists Versioning cannot be configured on external lists Item History is not available on external lists Datasheet view cannot be used in external lists XSLT is ...