Planning tool: Sample SharePoint Governance Plan



-913765249555000SharePoint Development Standards Prepared for9 May 2015Draft Number 1Prepared byPaul D. FoxContributorsRevision and Signoff SheetChange RecordDateAuthorVersionChange reference04/07/2014Paul D. Fox1.0Initial Draft for Review/Discussion05/09/2015Paul D. Fox1.1Updated Assembly & Component Naming ConventionReviewersNameVersion approvedPositionDateTable of Contents TOC \o "1-3" \h \z \t "Heading 9,9,Heading Part,9" 1.Objectives PAGEREF _Toc419140513 \h 12.Scope PAGEREF _Toc419140514 \h 13.Introduction PAGEREF _Toc419140515 \h 14.Roles and Responsibilities PAGEREF _Toc419140516 \h 15.Development Standard PAGEREF _Toc419140517 \h 16.General Development PAGEREF _Toc419140518 \h 26.1General Development Principles PAGEREF _Toc419140519 \h 26.2Branding: PAGEREF _Toc419140520 \h 36.3App Development (SharePoint 2013): PAGEREF _Toc419140521 \h 36.3.1SharePoint Development Virtual Machines (VM) PAGEREF _Toc419140522 \h 46.4Creating Visual Studio Projects PAGEREF _Toc419140523 \h 46.4.1Creating Assemblies PAGEREF _Toc419140524 \h 46.4.2Assembly Naming Conventions PAGEREF _Toc419140525 \h 56.4.3Creating Visual Studio Projects: PAGEREF _Toc419140526 \h 66.4.4Creating Feature Properties PAGEREF _Toc419140527 \h 76.4.5Web Part Properties PAGEREF _Toc419140528 \h 96.4.6Site Column Properties PAGEREF _Toc419140529 \h 96.4.7Site Content Type Properties PAGEREF _Toc419140530 \h 96.4.8Application Configuration PAGEREF _Toc419140531 \h 96.4.9Creating Deployment Properties PAGEREF _Toc419140532 \h 106.4.10SharePoint root Deployments PAGEREF _Toc419140533 \h 156.5Creating SharePoint Designer Projects PAGEREF _Toc419140534 \h 156.5.1SharePoint Designer Governance PAGEREF _Toc419140535 \h 156.5.2Creating SharePoint Designer Workflows PAGEREF _Toc419140536 \h 166.5.3Creating SharePoint Designer Artifacts PAGEREF _Toc419140537 \h 166.6Creating InfoPath Projects PAGEREF _Toc419140538 \h 166.6.1Choosing the Type of InfoPath Form to Use in an Application PAGEREF _Toc419140539 \h 166.6.2InfoPath Forms Designed for a Form Library PAGEREF _Toc419140540 \h 166.6.3Advanced Form Options PAGEREF _Toc419140541 \h 216.6.1Form Template Properties PAGEREF _Toc419140542 \h 246.6.2Page Layout PAGEREF _Toc419140543 \h 256.6.3Button Controls PAGEREF _Toc419140544 \h 256.6.4InfoPath Code Behind PAGEREF _Toc419140545 \h 256.6.5Formatting and Validation PAGEREF _Toc419140546 \h 266.6.6Data Connection Naming Convention PAGEREF _Toc419140547 \h 266.6.7Data Connection Libraries PAGEREF _Toc419140548 \h 276.6.8Sample Form (InfoPath) PAGEREF _Toc419140549 \h 296.6.9InfoPath Forms Designed for a SharePoint List PAGEREF _Toc419140550 \h 296.6.10Reverting List form back to default ASPX form from InfoPath PAGEREF _Toc419140551 \h 307.Deployment PAGEREF _Toc419140552 \h 317.1.1Change Log PAGEREF _Toc419140553 \h 317.1.2Deployment Folder PAGEREF _Toc419140554 \h 317.1.3Deployment Path PAGEREF _Toc419140555 \h 327.1.4Deployment Method PAGEREF _Toc419140556 \h 328.Source Code Control PAGEREF _Toc419140557 \h 398.1.1Microsoft Team Foundation Server (TFS) PAGEREF _Toc419140558 \h 398.1.2Connecting to a Team Project in TFS PAGEREF _Toc419140559 \h 398.1.3Mapping the Projects to the Local Drive PAGEREF _Toc419140560 \h 399.Appendix PAGEREF _Toc419140561 \h 409.1.1SharePoint 2010/2013 Best Practices PAGEREF _Toc419140562 \h 409.1.22013 Versioning Overview PAGEREF _Toc419140563 \h 409.1.3Feature Overview PAGEREF _Toc419140564 \h 419.1.4Capacity Planning PAGEREF _Toc419140565 \h 419.1.5Installation PAGEREF _Toc419140566 \h 419.1.6Upgrade and Migration PAGEREF _Toc419140567 \h 429.1.7Infrastructure PAGEREF _Toc419140568 \h 429.1.8Backup and Recovery PAGEREF _Toc419140569 \h 429.1.9Database PAGEREF _Toc419140570 \h 429.1.10Implementation and Maintenance PAGEREF _Toc419140571 \h 429.1.11Apps PAGEREF _Toc419140572 \h 439.1.12Every day use PAGEREF _Toc419140573 \h 439.1.13Add-ons PAGEREF _Toc419140574 \h 439.1.14Development PAGEREF _Toc419140575 \h 439.1.15Debugging PAGEREF _Toc419140576 \h 439.1.16Troubleshooting PAGEREF _Toc419140577 \h 449.1.17Farms PAGEREF _Toc419140578 \h 449.1.18Accessibility PAGEREF _Toc419140579 \h 449.1.19Top 10 Blogs to Follow PAGEREF _Toc419140580 \h 449.1.20Recommended SharePoint Related Tools PAGEREF _Toc419140581 \h 449.1.21Training PAGEREF _Toc419140582 \h 459.1.22Top 10 Thoughts before Developing in SharePoint 2010/3013 PAGEREF _Toc419140583 \h 459.1.23Six Critical Questions for any SharePoint Developer PAGEREF _Toc419140584 \h 469.1.247 Habits of Highly Effective SharePoint Developers PAGEREF _Toc419140585 \h 489.1.25SharePoint 2010/2013 Best Practices PAGEREF _Toc419140586 \h 49DevelopmentObjectivesThis document represents the <Company Name> SharePoint Development Standards.ScopeThis standard is to be followed for all SharePoint Development internally developed objects unless it is deemed unreasonable to do so by management. This does not apply to 3rd party-developed software products.IntroductionThe general purpose of this document is to provide the SharePoint Development team with a set of Development Standards with the intent of facilitating the deployment of consistently reliable, high quality solutions to the business.Roles and ResponsibilitiesSharePoint DevelopersResponsible for ensuring that his/her code follows the SharePoint Development Standard. Developers are responsible for checking adherence to the Development Standard.Team Lead/ Technical LeadResponsible for updating the Development Standard or waiving adherence to the standards in specific cases.Development StandardThe following rules will be followed in all .NET and SharePoint programming unless specifically agreed upon by the development team management.General DevelopmentGeneral Development PrinciplesAll new functionality and customizations must be documented. Do not edit out of the box files. (SharePoint Root Files)For a few well defined files such as the Web.config or docicon.xml files, the built-in files included with SharePoint Products and Technologies should never be modified except through official supported software updates, service packs, or product upgrades. Do not directly access the SharePoint databases. Any addition, modification, or deletion of the data within any SharePoint database using database access commands. This would include bulk loading of data into a database, exporting data, or directly querying or modifying data. Directly querying or modifying the database could place extra load on a server, or couldexpose information to users in a way that violates security policies or personal information management policies. If server- side code must query data, then the process for acquiring that data should be through the built-in SharePoint object model, and not by using any type of query to the database. Client-side code that needs to modify or query data in SharePoint Products and Technologies can do this by using calls to the built-in SharePoint Web services that in turn call the object model. Exception: In SharePoint 2010 and 2013 the Logging database can be queried directly as this database was designed for that purpose. Do not modify the SharePoint Database Schema. Any change made to the structure or object types associated with a databaseor to the tables included in it. This includes changes to the SQLprocessing of data such as triggers and adding new User Defined Functions. A schema change could be performed by a SQL script, by manual change, or by code that has appropriate permissions to access the SharePoint databases. Any custom code or installation script should always be scrutinized for the possibility that it modifies the SharePoint database Always use Visual Studio 2010, 2012 or 2013 to build custom solutions and always use Microsoft Team Foundation Server (TFS) to store source code.Never share a development environment with multiple developers.Never manually deploy files to SharePoint Servers. Always deploy using a Windows SharePoint Package (.wsp).Don’t break your development efforts up into a bunch of little Visual Studio solutions unless it makes good sense. (One solution is easier to manager and deploy than several)Content should always be created where it will live. Do not attempt to run content through development, staging and production deployment cycle.Use the Shared staging environment to ensure that all of the solutions you build work properly and integrate well with each other prior to deployment to production.Backup and Restore Site Collections from Production to Staging or Development if you need the content to test you custom solutions.Coordinate deployment to Staging Environment with the SharePoint Administrator. The Administrator only has rights to deploy to Staging and Production.Content is not code, do not attempt to manage it the same way.Do not attempt to build .NET assemblies greater than version 3.5 (for SharePoint 2010) or 4.0 (for SharePoint 2013) unless the product supports it via Service Packs.When creating custom artifacts (Features, Web Parts, etc.) do not allow these to be shown in the Site Collection Features or Site Features display list unless they are generally available to all users. Specific custom artifacts are to remain hidden and activated via PowerShell.All customizations must package any deployment files and manifests in either a SharePoint solution package or an App for SharePoint package for deployment to the SharePoint farm. The deployment package must include all deployment and configuration instructions for SharePoint to automatically apply, including any Web.config settings or changes.No customization may modify or overwrite the core SharePoint product and system files directly, including all ASPX, XML, JavaScript, CSS, and image files.All customizations that store any data are required to persist it to a SharePoint database through the SharePoint API or by providing its own dedicated data store.No customizations may query the SharePoint databases directly. You must use the API or CAML Query.All customizations must only access the file system in a read-only fashion, except for copying a customization’s files and assemblies during its initial deployment.No customization may implement its own caching solution and instead must use the SharePoint AppFabric or another persistence strategy available through the SharePoint API.All customizations must handle all exceptions gracefully and provide a friendly error message while recording any error details to the SharePoint ULS log when an error or exception condition exists.Customizations ought to avoid exhausting any SharePoint resources from servers in the SharePoint farm, and instead they should consume a web service to do their “heavy lifting” on another server dedicated to handle the customization’s load.Customizations ought to verify a requesting client has any necessary privileges for a particular resource or operation prior to attempting access, and where possible, suppress displaying a feature when a requestor lacks those privileges.Customizations ought to impersonate the requesting clients’ credentials for any privileged request and avoid using the SPSecurity.CodeToRunElevated method to minimize any elevated privileges and circumvented security risks.Customizations ought to access data in external systems through the Business Connectivity Services by providing definitions for any web services and databases the component needs to integrate with, rather than connecting to a system directly.Customizations ought to write tracing and error information to the SharePoint log file and allow a SharePoint administrator to set the verboseness of tracing information it writes.Customizations ought to make any user interface elements compatible with SharePoint themes and CSS classes.Customizations ought to explicitly specify and assert the minimum .NET Code Access Security permissions an assembly requires to minimize the scope of any potential security vulnerabilities.Customizations ought to create and consume dedicated Service Applications, where appropriate, to offload and isolate custom tasks and workflows associated with custom code.Use the .Net XML commenting system??????????????????????? ()When possible try to not store custom settings in the web.config file. Use a separate file on CONFIG folder.Ensure that each feature GUID is unique in the farm.Ensure that all the features have an appropriate name, description, updated version number and icon.Features with event receivers should clean up all changes created in activation as part of the deactivation routines. If the feature creates a list that contains user data, the feature should not delete this list.Farm and Web Application features should never be hidden.Ensure that new solutions have a unique GUID in the FarmThe solution package should not include any of SharePoint installed files.Referenced assemblies should not be set to copy local = 'true'. All prerequisites must be?communicated to the customer and pre-installed as stand-alone components for easier?administration.Tools for Quality Assurance:Use FXCop for identifying and fixing performance and security issues in source code.Use the to help identify security issues in the solution source code.Use StyleCop to identify code style and naming conventions issues.?Use the SPDisposeCheck toolBranding:A consistent user interface should be leveraged throughout the site. If a custom application is created it should leverage the same master page as the site. Editing out of the box master pages is not allowed. Instead, duplicate an existing master page; make edits, then ensure you add it to a solution package for feature deployment. When possible you should avoid removing SharePoint controls from any design as this may impact system behaviour, or impair SharePoint functionality.All Master Pages should have a title, a description, and a preview image. All Page Layouts should have a title, a description, and a preview image. App Development (SharePoint 2013): When developing an app select the most appropriate client API:Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model. Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST. Windows phone apps need to use the mobile client object model. If an App contains a Silverlight application, it should use the Silverlight client object model. Office Apps that also work with SharePoint need to use the JavaScript client object model. Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services ObjectsSharePoint Development Virtual Machines (VM)The following table lists the available SharePoint Virtual Machine instances for SharePoint Development:ServerIP AddressPurpose<Server Name><IP Address>SP2013 Developer Virtual Machine – Developer Name<Server Name><IP Address>SP2013 Developer Virtual Machine – Developer NameCreating Visual Studio ProjectsAll SharePoint related objects created must have <Company Name> specific names associated with it. The Name will identify the type of project and the class name. This includes Assemblies and artefact Folders deployed to the SharePoint root.The following are type’s possible projects that can be developed, Features, Web Parts, Field Types, Content Types, Workflow Activities, Site Columns, and Publishing Layout Pages.Creating AssembliesNote When a Project is associated with a specific Project ID such as those from the EPMO or a SharePoint Service Request, please use the Project ID as the last segment of the Assembly and SharePoint Artefact name (Includes Web Parts and Folder Names deployed to the “SharePoint root”).Only .NET Framework 2.0 - 3.5 is supported in SharePoint 2010Only .NET Framework 2.0 - 4.5 is supported in SharePoint 2013Examples: <Company Name>.SP.ER.DisableNewFolderOr (If a Service Request (SR Request Number) or Enterprise Project Management Office (EPMO Project Number) use the SR Request Number or EPMO Project Number.<Company Name>.SP.ER.SR558 (Where “SR558” is the SharePoint Service Request Number)So, in the example above, we have a <Company Name> owned Assembly that is for the SharePoint Platform, using the Event Receiver Feature for the Project request SR558.There is one folder designed to hold all the references for a given project. All assemblies must provide Assembly Information including versioning.Example:<Company Name>= Company NameSP= SharePointFeature= Platform Component<Feature Name>= Feature Name or Project NumberAssembly Naming ConventionsSharePoint Projects will be broken down into the following namespaces. These include all artifacts including those deployed to the SharePoint root. Example:Assembly PrefixPurposeExample<Company Name>.sp.er.<FunctionName>Event Receiver/Feature Receiver<Company Name>.sp.er.disablenewfolder<Company Name>.sp.pp.<FunctionName>Publishing Pages<Company Name>.sp.pp.portalpagelayouts<Company Name>.sp.wf.<FunctionName>Workflow<Company Name>.sp.wf.sp12345<Company Name>.sp.tj.<FunctionName>Timer Job<Company Name>.sp.tj.updategeologylist<Company Name>.sp.wp.<FunctionName>Web Part<Company Name>.sp.wp.listribbonmanager<Company Name>.sp.bc.<FunctionName>Business Catalogue<Company Name>.sp.bc.showopenorders<Company Name>.sp.ap.<FunctionName>Application Page<Company Name>.sp.ap.correlationidpage<Company Name>.sp.sd.<FunctionName>Site Definition<Company Name>.sp.sd.projects<Company Name>.sp.sa.<FunctionName>SharePoint App<Company Name>.sp.ap.sptipsandtricks<Company Name>.sp.ct.<FunctionName>Content Type<Company Name>.sp.ct.newsarticles<Company Name>.sp.oa.<FunctionName>Office App<Company Name>.sp.oa.wordconversion<Company Name>.sp.ca.<FunctionName>Cloud App<Company Name>.sp.ca.translator<Company Name>.sp.we<FunctionName>Workflow Extensions (Activity Extensions)<Company Name>.sp.we.userprofileactivities<Company Name>.sp.ws<FunctionName>Web Service<Company Name>.sp.ws.getgroupsgromuserCreating Visual Studio Projects:Visual Studio Projects may be developed on the Local Machine in the default configuration path of “C:\Projects\SP2013”. There are sub-folders within this path that coincide with the TFS Team Projects:C:\Projects\SP2013C:\Projects\PS2013I:\InfoPath\IP2013 (This can be a Shared Network Drive)Note There is a Path limit on Solution Names. This can cause the “Packaging” of Windows SharePoint Packages (.WSP) to fail. The work-around is as follows:From elevated command prompt (or ps console):Type: Subst “P:\ c:\path\to\solution\folder”Open the solution from P:\ to build it, telling Visual Studio to ‘work disconnected’ from source control.Make no changes to source while open from “P:\”! Only open it to create the package.The following example shows a Feature project created in Visual Studio 2013.Example:A strong name must be provided for Farm Level solutions and the Assembly Signing Key will contain either the name of the Assembly, or default to key.snk.Creating Feature PropertiesFeatures must have a unique GUID within the farm. Features with event receivers should clean up all changes created in the activation as part of the deactivation routine. The exception to this is if the feature creates a list or library that contains user supplied data. Do not delete the list/library in this instance. Features deployed at the Farm or Web Application level should never be hidden. Site Collection (Site Scoped) Features and Site (Web Scoped) Features may be hidden if necessary. Ensure that all features you develop have an appropriate name, description, updated version number and icon. All SharePoint Features must include the “FeatureImage.gif” and Alt Image tag in the Project Solution. The Feature image directory structure will be the same for each feature so that new folder paths are not needlessly created and duplicating the Feature Image Icon.Feature Image: FeatureImage.gif – ImageUrl: “<Company Name>.SP.ER.GlobalFeatures/FeatureImage.gif”Image Alt Text: “Feature Provided by <Company Name>.” <Company Name>/FeatureImage.gifNote Contact the <Company Name> SharePoint Development Team for a copy of this FeatureImage.gifExample: Assembly Name (<Company Name>.SP.ER.SR558), SharePoint Root Folder Name (<Company Name>.SP.ER.SR558)Where SR558 is the Project IDExample Feature in Site FeaturesAll Features must contain the Creator, Description, Feature Alt Text, Image Url, Title and Version.Example:PackageNote: When you create a Visual Studio 2013 feature project for SharePoint 2013, the standard nomenclature for the Feature folder path is:<FeatureManifests> <FeatureManifest Location="ProjectName_FeatureName\Feature.xml" /></FeatureManifests>Most of the time, my Assembly and Namespace are the same, so they appear duplicated in the “%<root>%/Template/Features” Folder.To shorten this Folder Name to just the Namespace (or Project Name) you can do the following:Double clicked on your feature to open the feature properties and find the Deployment Path propertyDeployment Path = $SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$Replace it with:Deployment Path = $SharePoint.Feature.FileNameWithoutExtension$Web Part PropertiesAll Web Parts must have a Title, Description, and associated Icon.Web Parts added to the Web Part Gallery will reside with the group “<Company Name> Custom Web Parts”Web Part assembly shall be named consistent with the assembly name followed by “.webpart”Example: /<Company Name>.SP.WP.ContentSlider.webpartSite Column PropertiesProgrammatically creating Site Columns shall not duplicate columns that already exist in SharePoint Out-of-Box unless the column properties do not meet requirements.Custom columns (SharePoint Internal Field Name) must be prefixed with “<Company Name>_”Custom columns shall be grouped within the “<Company Name> Custom Columns” grouping name.Site Content Type PropertiesProgrammatically creating Site Content Types shall not duplicate content types that already exist in SharePoint out of box.Custom Content Types shall be grouped within the “<Company Name> Custom Content Types” grouping name.Application ConfigurationThere are only a few methods in which application configuration data can be stored. When selecting the option that is right for the situation any decision maker must review this article Managing Custom Configuration Options for a SharePoint Application before making the decision. Web.config APIs such as the ConfigurationSection class and SPWebConfigModification class should always be used when making modifications to the Web.config file. HTTPModules, FBA membership and Role provider configuration must be made to the Web.config. Property Bags It is recommended that you create your own _layouts page for your own settings. It is also recommended that you use this codeplex tool to support this method Lists This is not a recommended option for Farm or Web Application level configuration data. It is also recommended that you use this codeplex tool to support this method Hierarchical Object Store (HOS) or SPPersistedObject Ensure that any trees or relationships you create are clearly documented. It is also recommended that you use the Manage Hierarchical Object Store feature at . This feature only stores values in the Web Application. You can build a hierarchy of persisted objects but these objects don’t necessarily map toSPSites and SPWebs. DatabasesWhen an application requires database storage, you must create databases outside of the SP Farm and reference them in code. Structural modifications to the SP Database Instance are not allowed and Application Specific databases should not reside with the SharePoint SQL Server Instance.Creating Deployment PropertiesIf required, ensure that the new solution version number is incremented (format V#. #.#). The solution package should not contain any of the files deployed with SharePoint. Referenced assemblies should NOT be set to “Local Copy = true” All pre-requisites must be communicated and pre-installed as separate solution(s) for easier administration. All Visual Studio Projects must have a “Deployment” folder where all artifacts are created for deployment. Create a New Folder in your project called: “Deployment”In your “Solution Explorer”, Right-Click on your Project and select “Properties”Select the “SharePoint” tab and choose “New” to create a new Deployment Configuration show below:Call this “Package Only” and select “Run Pre-Deployment Command”, then click “OK”.In the Pre-Deployment Command window, enter the following Note: You will need to replace the Project Solution Name with yours shown in red highlighting.To create the package, run the “Deploy” command from “Solution Explorer”. You will need to first create a new folder in your solution called “Deployment”. Include a ChangeLog.txt file that provides the SharePoint Administrator a brief summary of changes.Pre Deployment Command Linecopy /y "$(TargetDir)$(TargetName).wsp" "$(SolutionDir)<Company Name>.SP.ER.DisableNewFolder\Deployment\$(TargetName).wsp"There are two approaches available for deployment of SharePoint assets.PowerShell ScriptingWin32 Application (Preferred Method)PowerShell MethodCreate the associated PowerShell and Batch Files for Farm Deployment in the Deployment Folder. (see Appendix)DeploySolution.batRetractSolution.batUpgradeSolution.batSPSolutionDeploymentScript.ps1ChangeLog.txtNote The UpgradeSolution.bat should only be utilized when the upgrade contains the original deployed file structure. If the structure changes, you must Retract and Deploy the solution.Win32 MethodCopy the Win32 Application installer into your “Deployment” folder. You can obtain this application from the SharePoint Development team. (Your Pre-Deployment Command line will copy the .wsp to your “Deployment” folder.Setup.exe (<Company Name>.SP.Package.Installer.exe)Setup.exe.config (<Company Name>.SP.Package.Installer.exe.config)ChangeLog.txtConfiguring the “Setup.exe.config”You will need to configure this file prior to executing the installer. There are five primary settings to be made in this file.SolutionId – Enter the solution id obtained from the “Package.package” properties.FeatureId = Obtain the FeatureId from the Features Property. If there is more than one feature separate them by a comma.SolutionFile = Filename of the Windows SharePoint Package (.wsp)SolutionTitle = Descriptive title of the Solution being installed.All Visual Studio, SharePoint Designer and InfoPath artifacts must be must be documented and stored in Microsoft Team Foundation Server (TFS). TFS Server is located at: <SERVERNAME>, Team Project Collection: SharePoint2013ProjectsSite and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable. Custom code must be checked for memory leaks using SPDisposeCheck.If new Site definitions are required, use a minimal site definition with feature stapling.Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects SharePoint root DeploymentsNo out of the box SharePoint root files will be overwritten.Artifacts deployed must be deployed into an RGA/ProjectName folder. (The word feature in the feature name is not necessary as it gets deployed to the features folder in the SharePoint root)Do not deploy directly into the SharePoint Root Folders. Instead deploy into a folder identified by Project Name (Assembly Name). All custom SharePoint work must be deployed through SharePoint solutions (.wsp files) and use the Custom <Company Name> SharePoint Installer for Deployment or a Custom .bat file executing a PowerShell Script.Example Feature Deployed to SharePoint rootExample Deployment in “Solution Management”Creating SharePoint Designer ProjectsSharePoint Designer GovernanceSharePoint Designer updates are generally not allowed except for by a trained individual. The only exception to this rule is for creating Data Form Web Parts. The following is a recommended way of managing this aspect: These should be created using Scratch Pages, exported and imported to a site, or exported and packaged and deployed as a feature.This does not mean that SharePoint Designer should not be used for creating and testing branding artifacts such as master pages and page layouts. It is important for these artifacts to be deployed through solution files (WSPs) and typical build and deployment processes and not by manual methods. Editing out of the box master pages is not allowed. Creating SharePoint Designer WorkflowsSharePoint Designer workflows must be named (Titled) with the List Name or Process followed by “WF”Example: <ListName>WFCreating SharePoint Designer ArtifactsData View Web PartsWeb Parts created via SharePoint Designer must be documented and stored in TFS.Creating InfoPath ProjectsThe current version of InfoPath is InfoPath 2013 (Browser based).Choosing the Type of InfoPath Form to Use in an ApplicationList Form or Library FormA good rule of thumb to apply here is that a SharePoint list should not contain more than fifty columns. This is not a performance or engineering limitation, simply a practical matter of usability. A list with more than fifty columns becomes unwieldy to display and interact with, even when multiple list views are created to do so. If your application requires more than fifty columns of information, it most likely reflects the documentation requirements of a complex process or transaction and the information handling capabilities of a document-based form will be the appropriate choice. There are three fundamental differences between the functionality of a list form and a document-based form. The first is that the schema structure for a list form is flat; it is not possible to build hierarchical information sets with grouped and nested items. Nor can you apply repeating, optional, or choice behavior to individual elements or groups as was required by the New Initiative Approval process described above. This is because SharePoint lists are flat structures and the fields available for use in the form reflect that flatness. The second difference is the reduced set of controls available for use in a list form, reflecting the limitations of the flat structure of a SharePoint list and consequently the form behavior. The last difference is that a list form does not generate an XML document containing the information entered and gathered in the form based on the schema, as does a document-based InfoPath form. A list form is meant to populate the columns in the host list Path Forms Designed for a Form LibraryAll InfoPath forms must utilize the standard Header & Footer InfoPath Path Projects requiring code behind must be packaged as SharePoint Solution Files for Deployment or provide the path to the “Administrative Pick-Up Area” for the SharePoint Farm Administrator to deploy through Central Administration (Requires an Application Pool Recycle).All InfoPath form templates must contain a “Developer View”. This view will contain development documentation about Data Connections, Rules, and Special Coding etc.Standard font for fields and labels are to be Verdana 8Standard font for section labels are Verdana 10InfoPath Projects must be contained within its own folder structure using the forms naming conventionImportant: Always create a “Developer View” containing developer notes such as Data Connections, Connections that retrieve list data, etc.Example of Developer ViewAll InfoPath artifacts shall be stored within this folder (e.g. Context.xml. .doc, .xsn, .xsd, code behind files, ECT.) at the following Network Location. \\<SERVERNAME>\InfoPath Example Folder Name: C1000The “InfoPath_FormID_Cross_Reference.xlsx” file located at \\<SERVERNAME>\InfoPath shall be updated when new forms are generated to provide a cross reference between the Form ID (Cxxxx) and the Form Title.Naming Conventions:All objects created must have a <Company Name> prefix followed by the InfoPath Numbering scheme. You can obtain the last sequence number used from the list of forms located in the Source Safe Library.Example Form Name:CLS1000.xsn (Where CLS is the Prefix of a Company Name)Code Behind – All code behind enabled forms must have the source code and binaries located within a folder with the same name as the form name:Field Type NamesA Camel Case naming convention shall be utilized when naming InfoPath form Fields. Field Names that are promoted to SharePoint Lists should exceed 32 characters in length.Example: Field Type Naming ConventionInfoPath Template Source ControlSource Code Control will be located in Microsoft Team Foundation Server (TFS). These are accessed using Microsoft Visual Studio 2012 or 2013 (Professional, Premium or Ultimate) or Microsoft Team Explorer Everywhere 2012, or 2013.TFS Server is located at: <SERVERNAME>, Team Project Collection: InfoPathProjects“Connect to Team Project” image placeholderVisual Studio Team Explorer Image PlaceholderInfoPath Layout StandardsInfoPath forms will utilize one of the three available InfoPath Template Parts for standard Header and Footer. The template part to be utilized will depend upon the security requirements of the form. Available Template PartsVersionPurpose<Company Name>_Header.xtp22013Standard Form Header Template<Company Name>_Footer.xtp22013Standard Form Footer TemplateThese template parts (Design Controls) can be imported into your InfoPath Client Designer by selecting “Add or Remove Custom Controls” as shown below.Templates’ Parts are located at: \\<SERVERNAME>\InfoPath\TemplateParts\Advanced Form OptionsBrowser (All InfoPath forms are developed as “Browser” based forms)Use the Ribbon Options when possible (Submit and Close)Filler Features are not required for “Browser” based forms. These can be left as is or set to blank.Form Template PropertiesAdditional Form OptionsOfflineAs per RequirementsE-Mail AttachmentsAs per RequirementsProperty PromotionAs per RequirementsDigital SignaturesAs per RequirementsSecurity and TrustDomain Level unless requirements specify otherwise. If Full trust. Package into a Solution for Deployment or Publish to “Administrative Pick-Up Area” for Farm Administrator.PreviewAs per RequirementsProgrammingC# or VB (Specify the Path within the InfoPath Development Folder Structure)VersioningAutomaticCompatibilityDesign a form that can be opened in a BrowserAdvancedEnable form Merging: OptionalTreat Blank Values as Zero: YesPage LayoutLayoutPage SizeSection Headers are a maximum of 680 pixels wide. The form must be able to print within the 8 ? x 11 page boundary.Header Font10pt, Verdana, WhiteBody Font8pt, Verdana, BlackButton ControlsThe InfoPath 2010 Ribbon should be utilized for Form Submission however, when button controls are necessary, All Button Controls are to be sized as 8pt, Verdana, Black.Button Controls (InfoPath 2007)LabelSubmitSubmitCancelCancelInfoPath Code BehindIf Form Templates requires custom code (Code Behind), the source and Binaries should reside in a folder under the “TemplateName.xsn”. Source code can be written in C# or VB. InfoPath File Explorer Image PlaceholderNote: Writing Managed Code in InfoPath requires special deployment instructions. The Form Template must be published to an “Administrative Pick-Up Area” located on the InfoPath Development network drive or packaged as a Windows SharePoint Package (.wsp)InfoPath File Explorer “Administrative Pick-Up Area” Image PlaceholderForm Templates using Managed Code require them to be “Administrative Approved”. You must set the form option for “Security and Trust” to “Full Trust” and publish the form the “Administrative Pick-Up Area”. You will need to notify the SharePoint Farm Administrator to upload the form template through Central Administration (This requires completion of the “Go-Live Playbook” when deploying to a production environment).Formatting and ValidationAll formatting and validation should be provided based upon the requirements. Items such as Maximum Text Length, Valid Dates. Utilize Radio Buttons, Check Boxes or Drop down List boxes where appropriate in order to provide a measure of data integrity.Data Connection Naming ConventionThe data connection naming convention will follow the form name followed by the specific task of the connection.Example:Data Connection LibrariesThe preferred method for Data Connections when using InfoPath is the Data Connection Library in Microsoft SharePoint Server 2013. The Data Connection Library is a library that can contain two kinds of data connections: an Office Data Connection (ODC) file or a Universal Data Connection (UDC) file. Microsoft InfoPath 2013 uses data connections that comply with the Universal Data Connection (UDC) file schema and typically have either a *.udcx or *.xml file name extension. Data sources described by these data connections are stored on the server and can be used in standard form templates and browser-enabled form templates.Uploading data connection files to a Data connection library enables InfoPath form templates to use the data sources described by these files to retrieve and submit information.To create a SharePoint Data Connection LibraryBrowse to a SharePoint Server 2013 site on which you have at least Design permissions. If you are on the root site, create a new site before you continue with the next step.On the Site Actions menu, click More Options.On the Create page, click Library under Filter By, and then click Data Connection Library.On the right side of the Create page, type a name for the library, and then click the Create button.Copy the URL of the new data connection library.To create a new data connection file in InfoPathOpen InfoPath Designer 2013, click Blank Form, and then click Design Form.On the Data tab, click Data Connections, and then click Add.In the Data Connection Wizard, click Create a new connection to, click Receive data, and then click Next.Click the kind of data source that you are connecting to, such as Database, Web service, or SharePoint library or list, and then click plete the remaining steps in the Data Connection Wizard to configure your data connection, and then click Finish to return to the Data Connections dialog box.In the Data Connections dialog box, click Convert to Connection File.In the Convert Data Connection dialog box, enter the URL of the data connection library that you previously copied (delete "Forms/AllItems.aspx" and anything following it from the URL), enter a name for the data connection file at the end of the URL, and then click OK. It will take a few moments to convert and save the data connection file to the library.Confirm that the data connection was converted successfully by examining the Details section of the Data Connections dialog box while the name of the converted data connection is selected.Browse to the SharePoint data connection library, click the drop-down next to the name of the data connection, click Approve/Reject, click Approved, and then click OK.To use a data connection file in InfoPathOpen InfoPath Designer 2013, click Blank Form, and then click Design Form.Note If you want to use a data connection file to specify the main data source of a form template, you can use only a file that specifies a Database or Web service connection. To specify the main data source from one of these kinds of connections, click Data Connection File instead of Blank Form, and then proceed to step 3.On the Data menu, click Data Connections, and then click Add.In the Data Connection Wizard, click Search for connections on a Microsoft Office SharePoint Server, and then click Next.If the site where you created your data connection library is not listed in the Site drop-down list, click Manage Sites, and then click Add to add it to the list.Select the site where you had created your data connection library in the Site drop-down list, expand the name of the data connection library, select the data connection, and then click plete configuring the data connection in the Data Connection Wizard as required for the kind of connection that you have selected, click Finish, and then close the Data Connections dialog box.When finished, add some controls to the form, and then Preview the form to ensure that data is returned.Naming ConventionsUse the same Data Connection Naming Convention as listed above for naming Data Connection Files.Example: C1000_Submit.udcxSample Form (InfoPath)InfoPath Forms Designed for a SharePoint ListSharePoint 2013 provides the capability to convert the Newform.aspx, Editform.aspx and Dispform.aspx on SharePoint lists to utilize InfoPath 2013. When converted, the form names become newifs.aspx, editifs.aspx, displayifs.aspx.Limitations of List FormsWhen a SharePoint list is customized as an InfoPath form, there are several nuances to be aware of when it comes to the difference in form behaviour between a SharePoint page, a SharePoint list as an InfoPath form, and a form library form.Field Descriptions In the SharePoint list settings, each time a new column (field) is created, a description box is provided so that you can type a description of the data that should be entered in that field. If the description were to be changed at any point from the list’s settings, the default form would immediately reflect the change in the existing forms. When the form was converted to InfoPath, the description was still seen in the form. Unfortunately, when we wiped out the whole form to start from scratch with a new layout, the description did not come back when the Destination field was added back to the form.Field Types Similar to the Field Descriptions above, if the InfoPath form has been customized and you add, update or remove columns (fields), these list changes may not be reflected in the InfoPath form. For instance, if a new column (field) were added to the List, you will need to edit the InfoPath form and update the list references (xml schema). Afterwards, you will need to add the new column to the form layout.Data Connections In form library forms, there are no data connections at first, and each one must be created by using a wizard. However, a SharePoint list form inherently has a “submit” data connection that saves data to the current SharePoint list. This data connection cannot be removed or modified. Also, for each “choice” or lookup field that exists in the form, a “receive” data connection exists. These are also locked down and cannot be deleted or modified. However, new connections can always be added, with full functionality.Views with a SharePoint list form, multiple views can be created as with a form library form, but the behaviour is slightly different. When adding additional views, the view selection box becomes available in the InfoPath Ribbon and cannot be removed.Option Buttons These are not listed in the insert controls but can still be used in the form. Right-click a control, and in the Change Control To list, the option button is there.Custom Controls You cannot add custom controls to InfoPath Designer to utilize them in List Forms (i.e. Template Parts such as Header and Footer templates).No Developer Tab the Developer tab on the InfoPath Designer Ribbon is not available, which means that custom code cannot be added to these types of forms.Reverting List form back to default ASPX form from InfoPathYou can revert your form type back to the default .aspx forms by clicking on the “Form Settings” link in the List Settings and choosing “Use the default SharePoint form”.DeploymentAll SharePoint solutions must be packaged as a Windows SharePoint Package (.WSP) and deployed to Staging and Production by the SharePoint Administrator.All developers can deploy their own solutions to QA for deployment and unit testing.Change LogA Change Log is required to be maintained in the Deployment folder “ChangeLog.txt” which will contain each set of deployment changes by date of deployment.Sample Change LogDeployment FolderSolutions must be stored in a “Deployment” folder within the Project Solution. Each deployment will contain the following:SPSolutionDeploymentScript.ps1DeploySolution.batRetractSolution.batUpgradeSolution.batChangeLog.txtSample Deployment Folder:Visual Studio Solution Explorer Showing Deployment Folder Image PlaceholderDeployment PathTo provide the SharePoint Administrator your SharePoint Packages, you will need to copy the entire contents of the “Deployment” folder to the following location for SharePoint Administrator access. Each successive deployment of the same solution package will be placed within a sub-folder by deployment date.Deployment Paths:Internal Staging: \\<ServerName>\SharePointTemplatesInternal Production: \\<ServerName>\SharePointTemplatesSample Deployment PathFile Share Deployment Folder on Production CA Server Image PlaceholderDeployment MethodMethod 1 (PowerShell)If using Method 1 - Solutions must be deployed using the following PowerShell script and Batch Files.SPSolutionDeplymentScript.ps1#**********************************************************************************************#* SharePoint Solution Deployment/Upgrade/Removal Script#*#* Author: Paul D. Fox#* Created: 04/30/2014#* Purpose: To provide a Scripted solution to deploy and retract/remove SharePoint 2010#* solutions(.wsp).#* Modifications:#*#* Notes: To run this script open PowerShell for SharePoint 2010/2013 with Administrative#* privledges create the following batch (.bat) files:#* 1. DeploySolution.bat#* powershell -Command "& {Set-ExecutionPolicy bypass}" -NoExit#* powershell -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName: <Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:DeploySolution.log -action:SD}" -NoExit#* pauseRetraction Step#*#* 2. RetractSolution.bat#* powershell -Command "& {Set-ExecutionPolicy bypass}" -NoExit#* powershell -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName:<Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:RetractSolution.log -action:SR}" -NoExit#* pause #*#* 3. UpgradeSolution.bat#* powershell -Command "& {Set-ExecutionPolicy bypass}" -NoExit#* powershell -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName: <Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:UpdateSolution.log -action:SU}" -NoExit#* pause#*#*#* Copyright (c) <Company Name>#**********************************************************************************************param ( [string]$solutionName = "$(Read-Host 'Enter the Solution WSP Name. [e.g. Sample.wsp]')", [string]$webAppUrl = "$(Read-Host 'Enter the Web Application URL. [e.g. ]')", [string]$siteUrl = "$(Read-Host 'Enter the Site Collection URL. [e.g. ]')", [string[]]$siteFeatureNames = $null, #"$(Read-Host 'Enter the Site Level Features. [e.g. @('Feature1', 'Feature2')]')", [string[]]$webFeatureNames = $null, #"$(Read-Host 'Enter the Web Level Features. [e.g. @('Feature1', 'Feature2')]')", [string]$logFileName = "$(Read-Host 'Enter the Log File Name. [e.g. Sample.log]')", [string]$action = "$(Read-Host 'Enter [SD] to deploy solutions or [SR] to retract the solution, or [SU] to Update the solution')" ) # Defination of main function function main() { # find the current directory $currentDirectory = Get-Location # delete existing logfile $logFilePath = "$currentDirectory\$logFileName" if (Test-Path $logFilePath) { Remove-Item $logFilePath } # create new log file and start logging Start-Transcript $logFilePath # check to ensure Microsoft.SharePoint.PowerShell is loaded $snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'} if ($snapin -eq $null) { Write-Host "Loading SharePoint Powershell Snapin" Add-PSSnapin "Microsoft.SharePoint.Powershell" } # deploy the solution if ($action -eq "SD") { Write-Host "Step 1 - Add Solution Package: " $solutionName -foregroundcolor Green AddSolution Write-Host "Step 2 - Deploy Solution Package: " $solutionName -foregroundcolor Green InstallSolution Write-Host "Step 3 - Timer Job to deploy the Solution Package " -foregroundcolor Green Wait4TimerJob Write-Host "Step 4 - Activate Site Collection Level Features " -foregroundcolor Green ActivateSiteFeatures Write-Host "Step 5 - Activate Web Level Features " -foregroundcolor Green ActivateWebFeatures } # retract the solution if ($action -eq "SR") { Write-Host "Step 1 - Deactivate Web Level Features " -foregroundcolor Green DeactivateWebFeatures Write-Host "Step 2 - Deactivate Site Collection Level Features " -foregroundcolor Green DeactivateSiteFeatures Write-Host "Step 3 - Uninstall Solution Package: " $solutionName -foregroundcolor Green UnInstallSolution Write-Host "Step 4 - Timer Job to Retract the Solution Package " -foregroundcolor Green Wait4TimerJob Write-Host "Step 5 - Remove Solution Package: " $solutionName -foregroundcolor Green RemoveSolution } # upgrade the solutionif ($action -eq "SU"){ Write-Host "Step 1 - Upgrading Solution Package " -foregroundcolor Green UpdateSolution} # stop the logging Stop-Transcript } # Add the solution package # Adds a SharePoint solution package to the farm Solution gallery, It doesn't deploy the uploaded solution yet. function AddSolution() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} if ($solution -eq $null) { Write-Host "Adding solution package" -foregroundcolor Yellow $solutionPath = "$currentDirectory\$solutionName" Add-SPSolution -LiteralPath $solutionPath -Confirm:$false } } # Deploy the solution package # Deploys an installed SharePoint solution on all the WFE servers in the farm. # Deploying solution in the farm installs the feature automatically. It installs all the features # on each server at the farm, web, site collection, and site level but It doesn't activate them. # Since it provisions the file on each WFE, it is a timer job. function InstallSolution() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} $solutionId = $solution.Id if ($solution -ne $null) { $solutionDeployed = Get-SPSolution -Identity $solutionId | where-object {$_.Deployed -eq "False"} if ($solutionDeployed -eq $null) { if ( $solution.ContainsWebApplicationResource ) { Write-Host "Deploying solution package to web application: " $webAppUrl -foregroundcolor Yellow Install-SPSolution -Identity $solutionName -WebApplication $webAppUrl -GACDeployment -Confirm:$false } else { Write-Host "Deploying solution package to all web applications" -foregroundcolor Yellow Install-SPSolution -Identity $solutionName -GACDeployment -Confirm:$false } } } } # Activate the Site level features function ActivateSiteFeatures() { if ($siteFeatureNames -ne $null) { $spSite = Get-SPSite $siteUrl foreach($siteFeatureName in $siteFeatureNames) { Write-Host "Trying to Activate Site Collection Level Feature: " $siteFeatureName -foregroundcolor Yellow $siteFeature = Get-SPFeature -site $spSite.url | where-object {$_.displayname -eq $siteFeatureName} if ($siteFeature -eq $null) { Write-Host "Activating Site Level Features at " $spSite.url -foregroundcolor Yellow Enable-SPFeature –identity $siteFeatureName -URL $spSite.url -Confirm:$false } } $spSite.Dispose() } } # Activate the Web level features function ActivateWebFeatures() { if ($webFeatureNames -ne $null) { $spSite = Get-SPSite $siteUrl #Cycle through all webs in the collection and activate all the features foreach($spWeb in $spSite.AllWebs) { foreach($webFeatureName in $webFeatureNames) { Write-Host "Trying to Activate Web Level Features: " $webFeatureName -foregroundcolor Yellow $webFeature = Get-SPFeature -web $spWeb.url | where-object {$_.displayname -eq $webFeatureName} if ($webFeature -eq $null) { Write-Host "Activating " $webFeatureName " at " $spWeb.url -foregroundcolor Yellow Enable-SPFeature –identity $webFeatureName -URL $spWeb.url -Confirm:$false } } } $spWeb.Dispose() $spSite.Dispose() } } # Deactivate the Web level features function DeactivateWebFeatures() { if ($webFeatureNames -ne $null) { $spSite = Get-SPSite $siteUrl #Cycle through all webs in the collection and deactivate all the features foreach($spWeb in $spSite.AllWebs) { foreach($webFeatureName in $webFeatureNames) { Write-Host "Trying to Deactivate Web Level Features: " $webFeatureName -foregroundcolor Yellow $webFeature = Get-SPFeature -web $spWeb.url | where-object {$_.displayname -eq $webFeatureName} if ($webFeature -ne $null) { Write-Host "Deactivating " $webFeatureName " at " $spWeb.url -foregroundcolor Yellow Disable-SPFeature –identity $webFeatureName -URL $spWeb.url -Confirm:$false } } } $spWeb.Dispose() $spSite.Dispose() } } # Deactivate the Site level features function DeactivateSiteFeatures() { if ($siteFeatureNames -ne $null) { $spSite = Get-SPSite $siteUrl foreach($siteFeatureName in $siteFeatureNames) { Write-Host "Trying to Deactivate Site Collection Level Feature: " $siteFeatureName -foregroundcolor Yellow $siteFeature = Get-SPFeature -site $spSite.url | where-object {$_.displayname -eq $siteFeatureName} if ($siteFeature -ne $null) { Write-Host "Deactivating Site Level Features at " $spSite.url -foregroundcolor Yellow Disable-SPFeature –identity $siteFeatureName -URL $spSite.url -Confirm:$false } } $spSite.Dispose() } } # Retract the solution package # Retracts a deployed SharePoint solution from the farm entirely for all web application or given web application. # This step removes files from all the front-end Web server. # Please note that retracting solution in the farm uninstalls the feature automatically, if it hasn't uninstalled using UnInstall-SPFeature. # Since it removes the file on each WFE, it is a timer job. function UnInstallSolution() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} $solutionId = $solution.Id if ($solution -ne $null) { $solutionDeployed = Get-SPSolution -Identity $solutionId | where-object {$_.Deployed -eq "True"} if ($solutionDeployed -ne $null) { if ( $solution.ContainsWebApplicationResource ) { Write-Host "Retracting solution package from web application: " $webAppUrl -foregroundcolor Yellow UnInstall-SPSolution -Identity $solutionName -WebApplication $webAppUrl -Confirm:$false } else { Write-Host "Retracting solution package from all web applications" -foregroundcolor Yellow UnInstall-SPSolution -Identity $solutionName -Confirm:$false } } } } # Update the solution package # Updates a SharePoint solution from a farm solution gallery# Only use this function if the Solution Package contains the same set of files and features as the deployed solutionfunction UpdateSolution() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} if ($solution -ne $null) { Write-Host "Updating the solution package" -foregroundcolor Yellow$solutionLocation = "$currentDirectory\$solutionName"Update-SPSolution -Identity $solutionName -LiteralPath $solutionLocation -GACDeployment -Confirm:$false Write-Host "Solution Package Upgrade Completed" -foregroundcolor GreenSleep 3 } } # Remove the solution package # Deletes a SharePoint solution from a farm solution gallery function RemoveSolution() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} if ($solution -ne $null) { Write-Host "Deleting the solution package" -foregroundcolor Yellow Remove-SPSolution $solutionName -Confirm:$false Write-Host "Solution Package Removal Completed" -foregroundcolor GreenSleep 3 } } # Wait for timer job during deploy and retract function Wait4TimerJob() { $solution = Get-SPSolution | where-object {$_.Name -eq $solutionName} if ($solution -ne $null) { $counter = 1 $maximum = 50 $sleeptime = 2 Write-Host "Waiting to finish solution timer job" while( ($solution.JobExists -eq $true ) -and ( $counter -lt $maximum ) ) { Write-Host "Please wait..." sleep $sleeptime $counter++ } Write-Host "Finished the solution timer job" } } #Run the Main Function Main#**********************************************************************************************#* End Script#**********************************************************************************************DeploySolution.batpowershell -Version 3 -Command "& {Set-ExecutionPolicy bypass}" -NoExitpowershell -Version 3 -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName:<Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:DeploySolution.log -action:SD}" -NoExitpauseRetractSolution.batpowershell -Version 3 -Command "& {Set-ExecutionPolicy bypass}" -NoExitpowershell -Version 3 -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName: <Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:RetractSolution.log -action:SR}" -NoExitpause UpgradeSolution.batpowershell -Version 3 -Command "& {Set-ExecutionPolicy bypass}" -NoExitpowershell -Version 3 -Command "& {.\SPSolutionDeploymentScript.ps1 -solutionName: <Company Name>.SP.ER.DisableNewFolder.wsp -webAppUrl: -siteUrl: -siteFeatureNames:@('') -webFeatureNames:@('') -logFileName:UpdateSolution.log -action:SU}" -NoExitpauseMethod 2Method 2 is the new deployment method going forward. This method uses a custom installer “<Company Name>.SP.ER.PackageInstaller”.This installer contains the following files:Setup.exe (<Company Name>.SP.Package.Installer.exe) – Installer ExecutableSetup.exe.config (<Company Name>.SP.Package.Installer.exe.config) – Installer Configuration FileThe installer files can be obtained from the Deployment folder of the Visual Studio Project located in TFS. The configuration file will require modifications for each solution to be deployed. These are outlined below in red.SolutionId – Obtained from the “Package” properties in Visual StudioFeatureId – Obtained from the “Feature” properties in Visual StudioScope - Obtained from the “Feature” properties in Visual Studio<?xml?version="1.0"?><configuration>??<appSettings>????<add?key="BannerImage"?value="Default"/>????<add?key="LogoImage"?value="None"/>????<add?key="EULA"?value=""/>????<add?key="Require"?value="MOSS"/>????<add?key="MinSharePointVersion"?value="12.0.0.0"/>????<add?key="MaxSharePointVersion"?value=""/>????<add?key="SolutionId"?value="0399F229-136F-4f6c-AC47-8654CAE1984C"/>??????<!--?FarmFeatureId:?Old?way?to?specify?a?single?farm-level?feature????????????obsoleted?by?newer?FeatureId?key?-->????<add?key="FarmFeatureId"?value="159B735F-ADD5-45db-A232-BE5AF892B313"/>??????<!--?FeatureId:?Feature(s)?to?install/upgrade/repair??????????Either?a?single?GUID,?or?a?semicolon?delimited?GUID?list?-->????<add?key="FeatureId"?value="159B735F-ADD5-45db-A232-BE5AF892B313"/>??????<!--?FeatureScope:?Scope?of?feature(s)?specified?in?FeatureId??????????Legal?values:?Farm,?Web?Application,?Site,?Web-->????<add?key="FeatureScope"?value="Site"/>????<add?key="SolutionFile"?value="<Company Name>.SP.ER.DisableNewFolder.wsp"/>????<add?key="SolutionTitle"?value="Demo?Solution"/>??????<!--?SolutionVersion:?Version?of?solution:?this?value?is?stored?in?the?farm?property?bag?-->????<add?key="SolutionVersion"?value="1.0.0.0"/>????<add?key="UpgradeDescription"?value="Upgrades?{SolutionTitle}?on?all?frontend?web?servers?in?the?SharePoint?farm."/>????<add?key="RequireDeploymentToCentralAdminWebApplication"?value="true"/>????<add?key="RequireDeploymentToAllContentWebApplications"?value="false"/>??????<!--?DefaultDeployToSRP:?Whether?box?for?Shared?Resource?Provider?web?app?is?initially?checked????????????if?user?is?prompted?for?web?applications?to?target?-->????<add?key="DefaultDeployToSRP"?value="false"/>????<add?key="DefaultDeployToAdminWebApplications"?value="false"/>????<add?key="DefaultDeployToContentWebApplications"?value="false"/>??????<!--?PromptForWebApplications:?To?force?user?prompt?for?web?application;????????????useful?if?a?dll?is?included,?so?SafeControl?entries?needed,????????????but?feature?not?at?webapp?level?-->????<add?key="PromptForWebApplications"?value="false"/>??</appSettings><startup><supportedRuntime?version="v2.0.50727"/></startup></configuration>Source Code ControlMicrosoft Team Foundation Server (TFS)Microsoft Team Foundation Server 2013 is utilized as the primary tool for storing all SharePoint related artifacts. These include SharePoint, PowerShell for SharePoint and InfoPath.Connecting to a Team Project in TFS Select a Team Foundation Server <SERVERNAME>Wait for connection failure (30 seconds) then click on “Use different credentials” and login using your <Domain> accountConnect to Team Project Image PlaceholderSelect the Appropriate Team ProjectTFS Team Project Explorer Window Image PlaceholderTeam ProjectsDescription<Company Name> Intranet ProjectsSharePoint Artifacts Developed for “Intranet” Web Application<Company Name> Teams ProjectsSharePoint Artifacts Developed for Teams Web ApplicationWhen adding your solution to SharePoint TFS, you need to choose the appropriate Team Project Listed above.Mapping the Projects to the Local DriveIn Visual Studio 2012 or 2013 when you open up the Source Control Panel from the Team Explorer pane, you will need to map the TFS projects to your local drive. All local drives should be mapped to the following path: “C:\SharePointProjects”. If this path does not exist you must create it first.Visual Studio TFS Drive Mapping Image PlaceholderFor each project, click on the “Not mapped” link shown above and map to “C:\Projects” (Make sure the ‘Recursive’ is checked) and browse to the path.Visual Studio Workspace Mapping Image PlaceholderWhen asked to execute a “get” to retrieve the latest files, select ‘Yes’.AppendixSharePoint 2010/2013 Best PracticesIntroBest practices are, and rightfully so, always a much sought-after topic. There are various kinds of best practices: Microsoft best practices. In real life, these are the most important ones to know, as most companies implementing SharePoint best practices have a tendency to follow as much of these as possibly can. Independent consultants doing architecture and code reviews will certainly take a look at these as well. In general, you can safely say that best practices endorsed by Microsoft have an added bonus and it will be mentioned whenever this is the case. Best practices. These practices are patterns that have proven themselves over and over again as a way to achieve a high quality of your solutions, and it's completely irrelevant who proposed them. Often MS best practices will also fall in this category. In real life, these practices should be the most important ones to follow. Practices. These are just approaches that are reused over and over again, but not necessarily the best ones. Wiki's are a great way to discern best practices from practices. It's certainly possible that this page refers to these "Practices of the 3rd kind", but hopefully, the SharePoint community will eventually filter them out. Therefore, everybody is invited and encouraged to actively participate in the various best practices discussions. This Wiki page contains an overview of SharePoint 2013 Best Practices of all kinds, divided by categories.PerformanceThis section discusses best practices regarding performance issues. , the SharePoint Flavored Weblog Reader (SFWR) helps troubleshooting performance problems by analyzing the IIS log files of SharePoint WFEs. ?, PressurePoint Dragon for SharePoint 2013 helps executing performance tests. ?, a tool for checking capacity planning limits. ?, a command line tool for pinging SharePoint and getting the response time of a SharePoint page. ?, a WPF client for??for pinging SharePoint and getting the response time of a SharePoint page. ?, in depth info about performance counters relevant to SharePoint 2013. ?, TechNet performance monitoring tips. (x64) ?, the Web Capacity Analysis Tool (WCAT) is a lightweight HTTP load generation tool to measure the performance of a web server. Used by MS support in various capacity analysis plans. Improve SharePoint Speed by fixing a SSL Trust Issue, ?, Large Lists. ?, Estimating performance and capacity. 2013 Versioning OverviewThis section provides an overview of SharePoint 2013 versions.Beta 1 Preview 15.0.3612.1010 Beta 1 refresh 15.0.3919.1011 Beta 2 interim 15.0.4107.1000 Beta 2 public preview 15.0.4128.1014 Escrow / Release Candidate 15.0.4420.1006 RTM 15.0.4420.1017 Feature OverviewThis section discusses best places to get SharePoint feature overviews. ?, nice feature comparison. ?, extensive SharePoint Online overview. (v=office.15).aspx ?, deprecated features. ?, matrix overview. ?, nice overview including SharePoint 2013, 2010, 2007, and Office 365. ?, 2013 standard vs. enterprise. ?, 2013 standard vs enterprise vs foundation. ?, overview of all 2013 versions. Capacity Planning ?, excellent planning resource. ?, overview of various technical diagrams. ?, info about scaling search. ?, capacity boundaries. InstallationThis section discusses installation best practices.?, provides a detailed explanation how to create a SharePoint 2013 development environment. ?, system requirements overview. , provides an overview of the administrative and service accounts you need for a SharePoint 2013 installation. , describes SharePoint 2013 administrative and service account permissions for SQL Server, the File System, File Shares, and Registry entries. ?, naming conventions and permission overview for service accounts. , a methodical approach to upgrading to SharePoint 2013. ?, Automated SharePoint 2010/2013 installation using PowerShell and XML configuration. ?, GUI tool for configuring the AutoSPInstaller?configuration?XML. ?, describes how to set up a dev environment needed for creating Windows Apps that leverage SharePoint. ?, installing workflows. Install SharePoint 2013 on a single server with SQL Server Install SharePoint 2013 on a single server with a built-in database Install SharePoint 2013 across multiple servers for a three-tier farm Install and configure a virtual environment for SharePoint 2013 Install or uninstall language packs for SharePoint 2013 Add web or application servers to farms in SharePoint 2013 Add a database server to an existing farm in SharePoint 2013 Remove a server from a farm in SharePoint 2013 Uninstall SharePoint 2013 Install and configure a virtual environment for SharePoint 2013 Upgrade and MigrationThis section discusses how to upgrade to SharePoint 2013 from a previous version. Why SharePoint 2013 Cumulative Update takes 5 hours to install, improve CU (patch) Installation times from 5 hours to?30 mins.? best practices for upgrading from SharePoint 2007 to 2013. ?, upgrade SharePoint Foundation 2013 to SharePoint Server 2013. ?, SharePoint 2010 to 2013. ?, upgrade databases from SharePoint 2010 to 2013. ?, PDF document containing extensive info about Proven Practices for Upgrading or Migrating to SharePoint 2013. ?, upgrade from SharePoint 2007 or wss 3 to SharePoint 2013. InfrastructureThis section discusses infrastructure best practices.(v=office.15) ?, infrastructure diagrams. ?, dealing with geographically dispersed locations. Backup and RecoveryThis section deals with best practices about the back up and restore of SharePoint environments. ?, general overview of backup and recovery. ?, back-up solutions for specific parts of SharePoint. ?, good info about disaster recovery. ?, high availability architectures. ?, how to back up SharePoint online? Database ?, great resource about SharePoint databases. ?, removing ugly GUIDs from SharePoint database names. Implementation and MaintenanceThis section deals with best practices about implementing SharePoint. how to implement SharePoint. ?, rename service applications. AppsThis section deals with best practices regarding SharePoint Apps. (v=office.15).aspx ?, great resource for planning Apps. ,??a resource for building apps for SharePoint. , Best practices and design patterns for app license checking. Every day use?, using folders ?, discusses options for navigating up ?, discusses best practices for choosing between choice, lookup or taxonomy column Add-onsThis section deals with useful SharePoint add-ons. , an collection of web parts for an enterprise dashboard. , an app for iPhone/iPad that enhances mobile access to SharePoint documents. DevelopmentThis section covers best practices targeted towards software developers. , discusses when to use farm solutions, sandbox solutions, or SharePoint apps. ?, guidelines to help you pick the correct client API to use with your app. (v=office.15).aspx ?, guidelines to help you pick the correct client API for your SharePoint solution. ?, describes how to set up a development environment needed for creating Windows Apps that leverage SharePoint. ?, discusses how to deal with connection strings in auto-hosted apps. DebuggingThis section contains debugging tips for SharePoint.Use WireShark to capture traffic on the SharePoint server. Use a Text?Differencing tool to compare if web.config files on WFEs are identical. Use Fiddler to monitor web traffic using the People Picker. This will provide insight in how to use the people picker for custom development. Please note: the client People Picker web service interface is located in SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface. TroubleshootingTroubleshooting Office Web Apps ?, troubleshooting search suggestions. ?, troubleshooting claims authentication. ?, troubleshooting fine grained permissions. ?, troubleshooting email alerts. FarmsThis section discusses best practices regarding SharePoint 2013 farm topologies.Office Web Apps topologies How to configure SharePoint Farm How to install SharePoint Farm Overview of farm virtualization and architectures AccessibilityThis section discusses SharePoint accessibility topics. ?, shortcuts for SharePoint. ?, conformance statement A-level (WCAG 2.0). ?, conformance statement AA-level (WCAG 2.0). Top 10 Blogs to FollowIt's certainly a best practice to keep up to date with the latest SharePoint news. Therefore, a top 10 of blog suggestions to follow is included. Corey Roth at ? Jeremy Thake at Nik Patel at Yaroslav Pentsarskyy at Giles Hamson at Danny Jessee at Marc D Anderson at Andrew Connell at Geoff Evelyn at / , Nikander & Margriet on SharePoint. Recommended SharePoint Related ToolsWhat to put in your bag of tools? , the SharePoint Flavored Weblog Reader (SFWR) helps troubleshooting performance problems by analyzing the IIS log files of SharePoint WFEs. ?, PressurePoint Dragon for SharePoint 2013 helps executing performance tests. ?, a tool for checking capacity planning limits. , Muse.VSExtensions, a great tool for referencing assemblies located in the GAC. ?, helps with all your PowerShell development. In a SharePoint environment, there usually will be some. ?, Visual Studio extension based on PowerGUI that adds PowerShell IntelliSense support to Visual Studio. ?, FishBurn Systems provides some sort of CKSDev lite for 2012/SharePoint 2013. Very useful. ?, web extensions make creating CSS in a lot easier and supports CSS generation for multiple platforms. , the?SharePoint 2010 Administration Toolkit (works on 2013). ?, a great tool when you've installed your SharePoint farm on Azure. TrainingIf you want to learn about SharePoint 2013, there are valuable resources out there to get started. , basic training for IT Pros. ?, free eBook. ?, great resource with advanced online and interactive sessions. ? , at the end there's a nice overview of training resources. See AlsoSharePoint 2013 Portal Top 10 Thoughts before Developing in SharePoint 2010/30131. Is it out of the box?This might sounds very trivial but you should definitely consider analyzing what exists out of the box in SharePoint 2010/2013. This might be a well hidden web part or a forgotten template somewhere.Skill required: Power User in SharePoint2. Are you sure it’s not out of the box?Although legitimate to ask twice, I actually added this one to make sure I have a top 10 instead of a top 9 3. Is it available on ?Maybe someone like you needed the same (or close anyway) functionality and already published it and the source to the community. You can download, reuse, extend and modify whatever was available on the public community site CodePlex, definitely a time saver in some cases NoteCodeplex or other “Open Source code requires a copy of the source code and to be refactored into the above development standards for assembliesSkill required: Power User in SharePoint4. Can I buy a cheap (in terms of $$$ value, not quality please) web part or module from the net?There are thousands of web parts available for purchase on the Internet today ranging from $50 to thousands of dollars, still cheaper than start the full blown development lifecycle, testing, etc. Worth investing 30 minutes searching on good search engine of some 3rd party tools that may be already exist?Skill required: Power User in SharePoint5. Can I just customize SharePoint 2010/2013 components and lists?Leveraging custom lists, library settings, workflows, content types, metadata, columns validation, etc.Investigate if it is possible to fulfill your business requirements to stick with SharePoint configuration, customization and personalization using just your “mouse”. I used to be a programmer for almost 10 years and every time I was working with a software like this, I would try to “start from scratch” to have a “better control”. Not sure it’s a good ideaSkill required: Power User in SharePoint6. Can Office 2010/2013 suite be of any help?If you’re lucky enough to use Office 2010 or Office 2013, using customized information panel, ribbon customization, macros, Access Services, Excel Services, Visio Services, you might be able to build interesting applications as well.Skill required: Power User in SharePoint/Office7. Using InfoPath (with no code)Definitely investigate InfoPath as it is a very powerful easy-to-use tool for developing full blown application, electronic forms and web parts involving complex rules, interacting with multiple data sources in SharePoint or outside SharePoint via web services and even external data repository like SQL servers, Oracle DB, DB2, etc.At this stage, validate that your requirements can be done without coding as one can develop InfoPath with or without code.Skill required: Power User in SharePoint/InfoPath, Business Process Analyst8. SharePoint DesignerDepending on what you’re trying to accomplish, SharePoint Designer can be a great tool to build applications, templates, site branding, event handlers, custom workflows, lists customization, etc.Skill required: Power User in SharePoint Designer, Business Process Analyst9. InfoPath (with code)All the goodies from #6 but this time mix and match by adding some code (in or C#) to add more control and functionality to your application.Skill required: Developer for InfoPath, Business Process Analyst10. Visual Studio – To “rule them all”If you are still reading, chances are you are a developer and you can afford to know the SharePoint SDK/API and you are skilled in C#. In that case, this is the tool you want to be using. Visual Studio with SharePoint add-ins will allow you to create a full spectrum of applications ranging from web parts to condition/actions to export to SharePoint Designer, web services to expose to InfoPath or simply full blown customized applicationsSkill required: Professional DeveloperSix Critical Questions for any SharePoint DeveloperAlthough many organizations that use SharePoint employ internal developers to create custom solutions, every customer organization I’ve encountered in my ten years of SharePoint consulting has used external vendors for at least some development. These vendors include individual contractors, Microsoft Certified Partner firms like non-linear creations, and independent software vendors (ISVs) like Bamboo Solutions or K2.Whether you use internal employees or third-party vendors, and whether an application is a simple web part or complex business-process automation, you must not deploy it until you know it can be trusted. A poorly-written application can slow (or bring down) your entire SharePoint farm. It can destroy or corrupt data in your databases, or critical files on your servers. It can also circumvent your security, opening you up to all manner of attacks.Below are six critical questions that you must ask any SharePoint developer, internal or external.1. Is this a Sandboxed Solution?Prior to SharePoint 2010, the only option available to the customer was to deploy every solution as a Farm Solution, where files are deployed to the file system and the code runs in the same execution space as SharePoint itself. If the solution is well written and behaves itself (for example, by NOT hogging all the server memory and crashing the SharePoint site it lives in), this is not a problem. But since the quality of custom SharePoint solutions is fully dependent on the developer/vendor, deploying a Farm Solution calls for a lot of trust on the part of the server administrator/customerOvercoming the customer’s understandable reluctance to deploy Farm Solutions was the driving force behind the introduction, with the 2010 product release, of Sandboxed Solutions. Sandboxed Solutions are web parts, Lists or other SharePoint features that run isolated from your SharePoint sites. By default, a Sandboxed Solution cannot access or affect anything outside of the local SharePoint site; external databases, web services, and the file system are all off limits. Your server administrators can apply limits and quotas to the Solution, so that if it misbehaves by (for example) hogging server memory, SharePoint 2010 will shut it down.Your developers/vendor may complain that Sandboxed Solutions are additional work. They may say that they are too neutered and can’t do anything useful. However, for a solution that requires access only to the local sites, lists and libraries, the latter isn’t true. And Sandboxed Solutions can be given additional permissions safely by using something called Full Trust Proxies, which let your vendor’s code request specific rights, while remaining isolated from the SharePoint execution space.Now that we have Sandboxed Solutions, a SharePoint developer’s first question (and yours) when designing a new feature should always be, “can I write this as a Sandboxed Solution?”.2. If it’s not Sandboxed, does it run as fully or partially trusted?Sandboxed Solutions are still quite new, and do require extra work, so they are not yet the industry standard (this will change very soon). And there will always be some solutions that can run only as Farm Solutions. You will still have occasions, then, when it will be acceptable to deploy a Farm Solution. But if your vendor or in-house developer delivers you a Farm Solution, you must know if it partially or fully trusted. With a fully-trusted solution, your developer’s code can access the file system on your SharePoint servers, it can access the Windows Registry — it is pretty much an administrator. From a developer’s viewpoint, this is the fastest and easiest way to develop. But with the availability of Sandboxed Solutions and partially-trusted solutions, there are very few reasons for you to accept a fully-trusted solution.A partially-trusted solution has no innate rights, and must be explicitly granted permissions (in a special configuration file called a Code Access Security policy) to do anything. The developer must provide this file, which you can inspect.3. Does it use Elevated Privileges?If for some reason your vendor must provide you with a fully-trusted solution, you must not deploy it until you understand everything it is going to try to do.One of the key questions in the vetting process: does it use RunWithElevatedPrivileges? This is a SharePoint feature that is exactly what it sounds like. By default, when your vendor’s code tries to do something like access a SharePoint document, it impersonates the user browsing the page; the code can’t do anything the user can’t do. However, a fully-trusted solution (or a partially-trusted one granted the permission) can use RunWithElevatedPrivileges to temporarily impersonate an account that has Full Control of your SharePoint application. RunWithElevatedPrivileges is a powerful tool that must be used sparingly, because it can circumvent your carefully-planned SharePoint security.Something else that can circumvent your security is Feature Event Receivers.4. Does it use Feature Receivers?A Farm (non-Sandboxed) Solution can include small bits of code that run when your server administrator installs or uninstalls a custom solution. For example, the solution may depend on the existence of an external database; a Feature Event Receiver can confirm that the database exists, and create it if necessary.Feature Event Receivers enjoy full administrative privileges on your server farm, so it is very important that you fully understand what they are programmed to do.5. Where does it store configuration settings?Many applications need a place to store configuration settings (e.g., database connection strings, or a email address for alerts). If your vendor’s solution uses the main configuration file (web.config) for this purpose, you increase your risk because this file may be shared by hundreds of SharePoint sites on your farm, and the slightest typo can bring them all down.In general, an experienced SharePoint developer will not provide you a solution that requires manual entries to web.config. Instead, a Sandboxed Solution will keep its settings in a local SharePoint list, and a Farm Solution will do the same or include a Feature (or Feature Event Receiver) that adds settings to the web.config file automagically on installation (and removes them on uninstallation).6. Where does it log messages?Finally, an experienced vendor will develop a solution with extensive logging. Even if the code has been developed defensively and tested thoroughly (two other things you need to ask about), even the best software goes wrong occasionally. When that happens in a production environment, you need to know exactly what happened so it can be diagnosed and remedied.An application can log messages to the Windows event log, a database table, the SharePoint Unified Logging Service, or a SharePoint List. Before you deploy the solution, you need to know which of these places it logs to, what kinds of messages it logs (is logging too verbose? Too sparse?), and whether the logging can be configured (is logging off by default? Are there different modes — Errors Only, Verbose, etc.?). If there is no way for you to get enough information when something goes wrong to at least understand what happened, without involving the vendor, this is a sign of a poorly-designed solution.These questions are only a sampling of the kind of due diligence required of you as the owner of a SharePoint environment. As in any business relationship, the key ingredient is trust.7 Habits of Highly Effective SharePoint DevelopersIntroductionCustom application development is crucial to ensure you get SharePoint’s full value. SharePoint is a strategic investment, and if you are to realize full payback and get the most value, you will end up doing a fair amount of custom development.Customers don’t see SharePoint as a primary development platform or don’t incorporate it into their implementation strategy. Also many customers still only see SharePoint as an application, and not a platform.The seven habits for successful SharePoint implementation are:1. Drive a full develop strategy for SharePoint. Help customers understand what custom development means and the range of customization options. Then build it into a strategy – what are we going to do, what are we NOT going to do, and what are we going to do in the future? Custom app development is the riskiest SharePoint workload.2. Drive an information architecture. SharePoint combines elements of two information architecture approaches. When you have to go back and retrofit an information architecture into your deployment after the fact, it can be very painful. An effective IA will pay knowledge management dividends. Manual tagging is loathsome to users. Recommend using some kind of auto-tagging strategy.3. Design solutions you can easily migrate. Five rules for avoiding SharePoint migration pain in the future:Don’t mess with the standard UI modelDon’t build deep new services that change the server modelDon’t custom-integrate third-party productsStick to web standardsImplement a modular physical database architecture4. Supplement with 3rd party products. 3rd party product augmentation is very common with many companies doing it (57% according to Global SharePoint Usage Online Survey – July 2011). Some popular 3rd party products being used: Nintex, Bamboo, AvePoint, NewsGator, Axceler, K2, Kwizcom, Quest, Metalogix, Yammer5. Create your SDLCs. Like any other type of custom development, SharePoint requires a full software development life cycle. Many people make the mistake thinking that SharePoint development isn’t “real” development like strict .Net development is.Elements of a SharePoint life cycle for developers:Requirements/Use CasesDevelopment conventions and elementsDevelopment methodsSolution test and validationSolution build and deliveryOngoing management and updatesYou also need an SDLC for user-generated applications:Develop UI guidelinesDevelop coding standardsEstablish sandbox environmentImplement certification processMonitor application usage6. Formalize your packaging-development strategy. SharePoint in the cloud is the rarity. Most companies deploy SharePoint on-premises in their data centre (81% according to same survey referenced above in #4). Of those that didn’t use the cloud, only 17% said it was never even a consideration.Office 365 encourages SharePoint-in-the-cloud adoption.Office and SharePoint features mergedSharePoint’s features exposed as point servicesSubscriptions, not licensesReduces “technical complexity” concerns7. Get plugged in and stay engaged. I’m not sure if I missed this but I don’t think he elaborated on this point.This was a great session and I wholeheartedly agree on all the points made. It’s nice to get some validation to what I otherwise believed but didn’t realize were actually “habits of highly effective SharePoint developers”.SharePoint 2010/2013 Best PracticesIntroMSDN Sample Code Browser Installer (Desktop Browser Application) practices are, and rightfully so, always a much sought-after topic. There are various kinds of best practices: Microsoft best practices. In real life, these are the most important ones to know, as most companies implementing SharePoint best practices have a tendency to follow as much of these as possibly can. Independent consultants doing architecture and code reviews will certainly take a look at these as well. In general, you can safely say that best practices endorsed by Microsoft have an added bonus and it will be mentioned whenever this is the case. Best practices. These practices are patterns that have proven themselves over and over again as a way to achieve a high quality of your solutions, and it's completely irrelevant who proposed them. Often?MS best practices will also fall in this category. In real life, these practices should be the most important ones to follow. Practices. These are just approaches that are reused over and over again, but not necessarily the best ones. Wiki's are a great way to discern best practices from practices. It's certainly possible that this page refers to these "Practices of the 3rd kind", but hopefully, the SharePoint community will eventually filter them out. Therefore, everybody is invited and encouraged to actively participate in the various best practices discussions. This Wiki page contains an overview of SharePoint 2010 Best Practices of all kinds, divided by categories.Performance When implementing IT solutions, everybody will face the day where a customer isn't happy with the way an application is performing. Because of the complex infrastructure and vast amount of features of SharePoint, there are many ways to approach these issues. Because of that and the importance of the topic, our first category?outlines best practices to tackling performance problems. ?, perhaps the most comprehensive resource about solving SharePoint 2010 performance issues.? ?, performance study of virtualized small farm. ?, large farm performance study. ?, performance studies. ?, great series of articles about performance management. ?Managing large, up to multi-terabyte content databases. PlanningEvery SharePoint undertaking will at one point face the following questions: how long will it take, how much will it cost to implement, and how will we use it???, the first and so far only resource?covering this particular topic.??? , Maxer for SharePoint 2010 is a tool that checks for capacity boundaries in existing SharePoint farms.? ?, capacity management. , interpretation of a "typical" SharePoint project. , getting started. , adoption best practices. Installation, Removal, Configuration, and OperationThis section deals with best practices regarding the following questions: How to install SharePoint? How to configure it? How to keep it operating? All best practices are targeted towards the IT Pro. ?, provides advice on how to get and keep your environment up and running. This list is created by members of the Microsoft Consulting Services team. ?, provides advice for the IT Pro how to keep team collaboration sites manageable. Created by Microsoft Consulting Services. ?, discusses how to keep My Sites manageable. Created by Microsoft employees. ?, discusses content deployment best practices. Created by Microsoft employees. ?, SQL Server 2008 best practices. Created by Microsoft employees. ?, People and Profiles. Created by MS employees. ?, Search. Created by MS employees. , general considerations regarding service accounts. , discusses what to do when the crawl database becomes too large. , how to handle historical data in lists? , should you choose to use AD groups or SharePoint groups? , musings about the advantages of SPD. , be careful with list throttling settings. , row limits in external lists. , troubleshooting SSRS reports. , installing SharePoint 2010 and SQL Server 2012. , explains how to remove SharePoint in a clean and orderly fashion. ?, least privileges for administrative and service accounts. ?, least privilege model for service accounts. ?, least privilege user accounts. ?, account permissions and security settings. , a PowerShell script for quickly?creating SharePoint service accounts. DeploymentDeployment of software artifacts is important. This section discusses best practices. ?, deployment to different farm topologies. VirtualizationIt's very common that SharePoint farms use virtualization techniques. This section is dedicated to best practices concerning virtualization. , discusses virtualization best practices. Created by Microsoft Consulting Services. , performance tips for virtual PCs. Real Life UsageOnce you have SharePoint deployed, it's up to the end users, power users, and IT Pros to make the best of it. This section discusses best practices targeted towards this audience. , discussion of the use of Asset vs Picture libraries. , dealing with copying permissions between site collections. , best practices that help indexing content stored on file shares. , discussion whether a WCF service should be separate or run within SharePoint context. , discusses advantages of folders over views. , discusses whether to store data in SharePoint lists, external lists, or relational databases. Backup and RecoveryThis section deals with best practices about the back up and restore of SharePoint environments. ?, backup and recovery. , general backup and recovery guidelines. , discusses when to use SCA to perform backups. (office.14).aspx ?, provides good explanation of what get's backed up and when. DevelopmentThis section covers best practices targeted towards software developers. (office.14).aspx ??, setting up a development environment. ?, patterns and practices from MS Patterns and Practices group for developing applications in SharePoint 2010. , Visual 2010 requirements for developing SharePoint 2010 solutions. (v=office.14).aspx , best practices for SPF concerning suspending impersonation, unnecessary construction of SPSite and SPWeb objects, event receivers, disposing objects, file naming restrictions, handling large folders and lists, object caching techniques, and optimizing code performance. , disposing objects. (v=office.14).aspx , tips about writing efficient code. , Security Best Practices for Developers in SharePoint 2010. , Best Practices for Developing Sandboxed Solutions in SharePoint 2010 , SharePoint Guidance Hands on Labs by MS. , developing applications for SharePoint 2010. , creating an IDisposable class for lists so you won't forget to dispose SPSite and SPWeb objects. , SharePoint MVC pattern. , SharePoint MVP pattern. , which API should you use: SharePoint object model/web services/client object model/custom WCF service leveraging server object model? , best practice for determining the current user in a SharePoint workflow. , create a separate WCF service or a WCF service in SharePoint context? , how to retrieve the current user in a SharePoint workflow. ?MICROSOFT SHAREPOINT ONLINE CODE ANALYSIS FRAMEWORK (MSOCAF) This application have code rules that can be used to validate SharePoint Solutions. SearchSearch is a complex topic and important to almost every company working with SharePoint. This section discusses best practices.(v=office.12).aspx , when to crawl content.? ?, FAST search topology.?, how to use a dedicated web server for crawling.Upgrade and MigrationIf a product is successful, it has to be upgraded at some point. , reviews upgrade best practices. , video of best practices. , video about Upgrade lessons learned by MS. , preparing for upgrade. , video about upgrade and migration best practices. Extranet EnvironmentsThis section provides an overview of planning and design considerations for SharePoint Extranet Environments. ?, provides advice regarding SharePoint Extranet environments. Created by members of Microsoft Consulting Services. ?, extranet topologies. ?, extranet topologies and firewalls. ?, more extranet topologies. FarmsThis section discusses best practices regarding SharePoint 2010 farm topologies. ?, discussion of three supported topologies: Single Data Center High-Availability Model, Cross-Site High-Availability Model, and Multiple-Farm Cross-Site Model. ?, technical diagrams of recommended solutions. ?, common ways to build and scale farm topologies. ?, nice explanation of basic terminology. ?, scale out from a 2-tier farm to a 3-tier farm. ?, topology and licensing example of medium farm. ?, examples of diagramming SharePoint topologies. ?, 3-tier farm. ?, discussion of basic types of deployment. Top 10 Blogs to FollowIt's certainly a best practice to keep up to date with the latest SharePoint news. Therefore, a top 10 of blog suggestions to follow is included. , the SharePoint Developer team blog. , Andrew Connell on SharePoint. , Joel Oleson's SharePoint Land. , Nikander & Margriet on SharePoint. , the SharePoint guys. , Nothing but SharePoint. , Scot Hillier on SharePoint. , Lightning Tools Blog. , Wictor Wilen on SharePoint. , Gokan Ozcifci on SharePoint Top 5 SharePoint BooksBooks remain the most important resource for learning a new topic. Here's a suggestion of the best SharePoint 2010 books out there. ?, the favorite developer book about SharePoint 2010. ?, great resource for administrators. ?, does a great job teaching SharePoint end users and power users. ?, dedicated to SharePoint Designer 2010. ?, best book out there about SharePoint 2010 web parts. Top 10 SharePoint ToolsWhat to put in your bag of tools? ?, CKSDev makes SharePoint development easier. ?, SharePoint Manager is a SharePoint object model explorer. ?, :? IntelliSense for CAML. ?, CAML Designer makes creating CAML queries a lot easier (successor of?U2U CAML Query Builder). ?, you'll always need a tool to view the ULS log files. ULS Log Viewer is probably the most popular one of the lot. ?, the SharePoint Maxer tool helps checking for capacity planning limits. ?, the SharePoint Flavored Weblog Reader (SFWR) helps troubleshooting performance problems by analyzing the IIS log files of SharePoint WFEs. ?, the Migration Dragon for SharePoint 2010?is a tool that can help to migrate file and folder structures from the file system to SharePoint 2010 Document Libraries leveraging the batching mechanism of the SharePoint managed client object model. ?, Muse.VSExtensions, a great tool for referencing assemblies located in the GAC. ?, jQuery Library for SharePoint Web Services ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download