Monday, October 24, 2016

Disadvantages of Sandbox solutions

1. Deployment at site collection level (No Web Application-scoped Features or Farm-scoped Features). So, If you have 100 site collections, then you have to deploy the same sandbox solution to 100 site collections.

2. No SPSecurity - Therefore no Elevated Privileges

3. You can't use SPSite object to get other site collections. (But you can use it to get current site as : SPSite site = SPContext.Current.Site)

4. Visual webparts are not supported (But you can use the "Visual Studio 200 SharePoint Power Tools" to get this functionality)

5. cannot call to the network resources. E.g. You cannot read/write to a database on the server (But you can use Silverlight)

6. Only "No code" workflows allowed. No Visual studio workflows (But the workflows without classes which are imported and edited in Visual studio will work!)

7. No support for System.IO, Therefore you Cannot read/write to the file system.(But you can use Web Services hosted in your on-premises and call from workflow)

8. HideCustomAction, CustomActionGroup are not allowed. But you can use <CustomAction>

9. Remember, Resource Usage Quotas/Limits applied on Sandboxed solutions http://msdn.microsoft.com/en-us/library/gg615462.aspx

10. No Feature stapling supported.

11. Can't write to registry (But you can read)

12. Limited Server Object Model MSDN: http://msdn.microsoft.com/en-us/library/gg615454.aspx

13. Can't set cookies in the sandbox. Use JQuery plugin instead http://plugins.jquery.com/project/cookie

14. No call to external WCF/web services such as HTTP calls (But we can use AJAX)

15. Content Type Binding is not supported

16. No support for custom Timer jobs

17. Can't use SharePoint mapped folders such as _layouts

18. Can't export a Sandboxed Web Part

19. Microsoft.SharePoint.WebControls and Microsoft.SharePoint.WebPartPages Namespace are not available. So you have no access to CssRegistration class, But you can use: <Link> tag for style sheets!

20. Managed Metadata - No programmatic access to taxonomy object model.

21. No ADO.NET support!

22. No support for SPUtility.SendEmail, So you can't Send Mails using this class.

23. No caching support

24. No Custom HTTP Modules

25. No developer dashboard

26. No Site Definition

27. Can't use controls for delegation

28. No Business Connectivity Services support

29. No Localization support

30. No SPWebConfigModification usage

31. Most of the Microsoft.SharePoint.Administration are disabled

32. No Document converters

33. No User Control support.

34. NO Custom service applications

35. SharePoint web controls (such as SPTreeView) are not supported

36. ClientScriptManager is not available - No access to ScriptManager.

37. Can't access the event viewer for logging

38. No PropertyBags of SharePoint Object model are not accessible,( But you can use SPWeb.AllProperties or custom list to store settings)

39. No GAC Deployment - Your solutions will be stored in content database. Can't deploy assemblies to GAC and Cannot call assemblies deployed out of Global Assembly Cache

40. CustomPropertyToolPart not supported

41. Can't create application pages or site pages with code behind

42. No Server side redirects, such as Response.Redirect, Server.Transfer, SPUtility.Redirect.

43. Can't access some of the enterprise services like UserProfile, Search

44. Can't access dlls from BIN and resources files(.resx)

45. Can't access code that is not marked to allow partially trusted callers

46. Can't access Cache object.

47. HttpRequest.Files collection will not contain anything

48. Only SPLimitedWebPartManager is available.

49. SharePoint Web controls (namespace SharePoint.WebControls) are not available,

50. Last but not least: site Template Binding is not supported.

Tuesday, October 11, 2016

What is Synchronous and Asynchronous ?

In Simple words and in non technical terms

SYNCHRONOUS

You are in a queue to get a movie ticket. You cannot get one until everybody in front of you gets one, and the same applies to the people queued behind you.

ASYNCHRONOUS

You are in a restaurant with many other people. You order your food. Other people can also order their food, they don't have to wait for your food to be cooked and served to you before they can order. In the kitchen restaurant workers are continuously cooking, serving, and taking orders. People will get their food served as soon as it is cooked.

---------------------------------------------------------------------------------------------------------------------

SYNCHRONOUS

When executing a sequence like: a>b>c>d>, if we get a failure in the middle of execution like:

fail

Then we re-start from the beginning:

Like below:

this is synchronous

----------------------------------------------------------------------------------------------------------------------------

ASYNCHRONOUS

If, however, we have the same sequence to execute: a>b>c>d>, and we have a failure in the middle:

fail

...but instead of restarting from the beginning, we re-start from the point of failure:

Like below:

...this is know as asynchronous.

Sunday, October 9, 2016

Webparts errors

Unable to display this Web Part" on Data Views after restoring site from backup
“The name ‘InitializeControl’ does not exist in the current context”- Visual Web part
InitializeControl doesn't exist
Error Occurred in Deployment step 'Recycle IIS Application Pool'
Recycle IIS Application Pool’: 0x80070005 Access denied
Error handling in web part
Web Part Error: Access denied. You do not have permission to perform this action or access this resource' with some correlation ID.'
Webparts doesnt show up in webpart gallery, what might be the reason
A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.

Thursday, September 22, 2016

Sharepoint Admin - Roles and Responsibilities

SharePoint Administrator

The role of SharePoint administrator includes setting up the SharePoint infrastructure with servers and services; SharePoint 2007/2010, Exchange Server, Active Directory, Windows 2003 and 2008 Servers, SQL Server 2005/2008, IIS 6.0 and 7.0, network infrastructure, ISA server, etc. He is responsible for maintaining and optimizing the SharePoint farm.

A SharePoint administrator requires knowledge of both SQL Server and Windows Server. Since SharePoint stores all of its data in SQL Server databases, DBA knowledge is critical. However, the Windows Server knowledge required to build and maintain a SharePoint farm is considerable. The administrator role is often split between two people who work closely together: a Windows Server administrator and a SQL Server DBA.The DBA skills required are the standard set required for any SQL Server but the features of Windows Server that a SharePoint Administrator needs to have some knowledge of include:

Good knowledge in IIS and the architecture of it

Windows Server Manager

Active Directory (LDAP,ADLDS,ADAM etc)

DNS and SMTP

Network Load Balancing (NLB)

Firewall (Hardware and software NLB)

Event Viewer and Performance Monitor

PowerShell scripting will be added advantage if looking in SharePoint 2010

Managing and checking the overall server health and functionality

Monitoring SharePoint disk space usage through the built-in SharePoint reports for each site collection

Managing SharePoint permissions

Analyzing and reporting upon SharePoint usage and activity

Moving/copying sites

Supporting network load balancing needs and ensuring its correct operation (NLB)

Regular review of the events and messages reported in Event Viewer and Performance Monitor

Regular review, clean-up, management and configuration of SharePoint accounts and sites. This portion of the role will work closely with an Active Directory administrator if they are separated.

Regularly analyzing SharePoint content and storage

Monitoring SharePoint trends (e.g. site usage and growth, disk space usage and growth)

Setting up alerts and enforcing policies

Regularly auditing your SharePoint environment

Identifying and reporting governance violations

Checking for operating system, SQL Server and SharePoint patches and cumulative updates.

Daily Activities

1. Review Windows Event Logs for high-priority issues

2. Review the SharePoint Logs for high-priority issues

Weekly Activities

1. Review Search Usage reports

2. Attempt searches upon typical end-user searches – verify they work properly

3. Verify Alerts are functioning properly

4. Enhance search through audit of Search patterns (implementation of noise words, best bets,

keywords, thesaurus entry, etc.)

5. Review and maintain current BI cubes and web parts (if applicable)

6. Audit server utilization (disk IO, disk space, CPU, etc.) and update baseline

7. Review past week questions and issues and update FAQ

8. Ensure off-site backup procedure working properly

Monthly Activities

1. Review overall server architecture based on current use

2. Audit individual server design (each server)

3. Review released patch list for Windows Operating System, SQL Server and SharePoint

4. Apply patches per the pre-defined patch approach

5. Review patches or maintenance to third party controls (web parts, iFilters, etc.)

4. Review overall server architecture diagrams and documentation for updates and revisions

5. Review search architecture for new areas to index, crawl or exclude

6. Report on SharePoint uptime and SLA compliance

7. Review security hierarchy

8. Review new functions or sites deployed. Determine if training needs to be updated

9. Verify backups are valid and contain data

Quarterly Activities

1. Review company disaster recovery plan

Annual Activities

1. Exercise a company disaster recovery plan

Tuesday, July 5, 2016

Sharepoint Errors and Solutions

Internet Explorer cannot display the webpage (of a new web application).

We've all done it. You create the web application in Central Administration and then immediately jump to the browser to admire your new site. But there's nothing there. This usually happens when you are trying to show someone how easy it is to provision a site with SharePoint.

Oops. We missed a step. You need to create a site collection before you will be able to see anything. Obvious, but you'd be surprised how often it happens during the quick demo under pressure.

Central Administration->Application Management->Site Collections->Create Site Collections. Don't forget to select the right web application.

Still not working? If you are using a port other than 80 you might need to check your firewall rules. Also you may need to configure DNS records. If you did that and it still can't resolve it, try doing an ipconfig /flushdns on the client.

Cannot connect to the configuration database

This error message usually indicates a network connectivity problem between the SharePoint server and SQL Server machines. Check for network problems and firewall settings. These are the things most likely to have changed that our outside your control.

Check that your application pool account has permissions to the SQL Server database. Changes to the SQL Server configuration can also be a cause, and might have changed without your knowledge.

It can also be caused by the SQL Server database not running or offline. Check this by going to Services on Server and ensuring that the SQL services are running (MSSQL-----).

Access denied by Business Data Connectivity

You have created an External Content Type, probably in SharePoint Designer. You have finally onfigured authentication correctly (after a couple of false starts - you have figured which account it is using to connect to the database, and you have configured the database to allow that account access to the correct database). You have created a list based on that external content type.

And still you can't see the data. You still missed something. Sheesh.

Oh, yes, of course. You need to go into your Business Data Connectivity Service Application, and set the permissions on the object. First, go to Central Administration->Application Management->Manage service applications. Find your Business Data Connectivity service application and go to the Manage page. Select the external content type and go to Set Permissions on the ECB menu, or the Set Object Permissions on the ribbon. From the Set Object Permissions pop-up dialog page you can add accounts and set their permissions. You will need to give the user who is logging in to SharePoint at least Execute permission to be able to see the list items. Note that this is nothing to do with the account that will access the database - that's another issue.

When you change these permissions it can take up to a minute before the behaviour changes as seen in the user's browser, particularly if the BCS service is running cross-farm. By the way, you only need to add the "Execute" permission to view the contents of the external list.

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

This is what happens if you try to use pass-through authentication (also known as "User's Identity" when configuring the external content type in SharePoint Designer), and the database is on a separate server, and you are using NTLM.

With pass-through you are asking BCS to use the identity of the currently logged-in user to talk to the database (or other external system). This is not a bad strategy if you are giving individual users access to your database. The problem arises if the database is on another machine, because NTLM doesn't have the ability to pass the identity on (a process called delegation) and will instead try to connect to the back-end system anonymously. This is commonly known as the "double-hop problem".

There are a couple of ways around this. One is to implement Kerberos, which is nothing like as difficult to configure as some people suggest. But it isn't trivial. The other option is to use impersonation by making use of the Secure Store Service. The Secure Store Service can be configured either to cache a user's credentials (which means they will have to enter them again at some point when prompted), or you can configure a database access account and allow a group of users to use this account. The drawback of this second method is that you lose the audit trail of who did what in the database.

I suppose a third option is to use the trusted subsystem model and let the account running BCS have access to the database (sometimes referred to as RevertToSelf). This is okay for test and development systems but is probably not sufficiently robust security for production use.

The changes cannot be saved to the system definition, because the entered connection properties contain invalid values.

RevertToSelf, so named because of the method call used to implement it, is an authentication method in which the identity of the process running BCS is used to access the back-end system (usually a database such as SQL Server). It is also known as "BDC Identity" in the dialogs of SharePoint Designer. This allows you to use the trusted subsystem model of authentication against a back-end system.

Whether you should do this at all on a production server is perhaps another matter for security experts to debate. Anyway, for whatever reason, that is what you are trying to do. Seems simple enough - what could possibly go wrong?

I turns out this is disabled by default (are they trying to tell you something?). To enable it, you need to do a bit of work with PowerShell on the server, thus:

$bdc = Get-SPServiceApplication | where {$_ -match "Business Data Connectivity"}

$bdc.RevertToSelfAllowed = $true

$bdc.Update

Cannot connect to the LobSystem (External System).

Sometimes the message gets lost in translation. A colloquialism finds its way into the names of XML elements and error messages. What is a lobsystem? And what has it got to do with databases and external content types? I'm just visualizing a lobster. Then again, that may be because it's nearly lunchtime and I'm getting hungry.

So, presumably, the author of this message was thinking of a LOB System, where LOB is an acronym for "Line of Business". And some databases and back-end systems contain information connected with a particular business line, if the back-end system contains business data, and if the system is a business system at all. So the notion of an LOB System becomes somehow synonymous with any kind of back-end system that you are talking to using BCS. So it means you can't talk to the database. Aha! Thank you.

And the most common reason for not being able to get to the database, apart from someone forgetting to plug it into the network or switch it on, is permissions. And usually the database is SQL Server and we don't have permissions set up in SQL Server. Remember that the user account that needs access to the database will depend on the method used to authenticate. If you use pass-through or impersonation using Secure Store Service (individual) it will be the user's identity. If you use RevertToSelf it will be the BDC identity, which means the application pool account. If you are impersonating using a group account it will be the account you set up in the Secure Store Service when you set up the application.

You can quickly check for problems by going to the database server and looking in the application event log for the tell-tale SQL Server authentication errors. For a good article about dealing with this problem see this blog post.

Monday, July 4, 2016

Sharepoint development Standards

SharePoint Development Standards

This is only meant as application specific standards. You should always review these standards along with regular development standards which identify things like naming conventions and approaches.

General Principals:

· All new functionality and customizations must be documented.

Do not edit out of the box 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 modify the Database Schema.

Any change made to the structure or object types associated with a database or to the tables included in it. This includes changes to the SQL processing of data such as triggers and adding new User Defined Functions.

o 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.

· Do not directly access the databases.

o 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.

o Directly querying or modifying the database could place extra load on a server, or could expose 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 the Logging database can be queried directly as this database was designed for that purpose.

· In SharePoint 2007 site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

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

Development Decisions:

There are plenty of challenging decisions that go into defining what the right solution for a business or technical challenge will be. What follows is a chart meant to help developers when selecting their development approach.

	Sandbox	Apps	Farm
When to use	Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions.	Best practice. Create apps whenever you can.	Create farm solutions when you can’t do it in an app. See http://www.learningsharepoint.com/2012/07/20/sharepoint-2013-apps-vs-farm-solutions/ for more info.
Server-side code	Runs under a strict CAS policy and is limited in what it can do.	No SharePoint server-code. When apps are hosted in an isolated SharePoint site, no server-code whatsoever is allowed.	Can run full trust code or run under fine grained custom CAS policies.
Resource throttling	Run under an advanced resource management system that allows resource point allocation and automatic shutdown for troublesome solutions.	Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model.	Can impact SharePoint server-farm stability directly.
Runs cross-domain	No, and there’s no need to since code runs within the SharePoint farm.	Yes, which provides a very interesting way to distribute server loads.	No, and there’s no need to since code runs within the SharePoint farm.
Efficiency/Performance	Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead.	Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable overhead.	Very efficient.
Safety	Very safe.	Apps rely on OAuth 2.0. The OAuth 2.0 standard is surrounded by some controversy (for example, check out what OAuth lead author Eran Hammer has to say about it here: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ . In fact, some SharePoint experts have gone on the record stating that security for Apps will become a big problem. We’ll just have to wait and see how this turns out.	Can be very safe, but this requires additional testing, validation and potential monitoring.
Should IT pros worry over it?	Due the the limited CAS permissions and resource throttling system, IT pros don’t have to worry.	Apps are able to do a lot via the client OM. There are some uncertainties concerning the safety of an App running on a page with other Apps. For now, this seems to be the most worry-able option, but we’ll have to see how this plays out.	Definitely. This type of solutions run on the SharePoint farm itself and therefore can have a profound impact.
Manageability	Easy to manage within the SharePoint farm.	Can be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this.	Easy to manage within the SharePoint farm.
Cloud support	Yes	Yes, also support for App MarketPlace.	No, on-premises (or dedicated) only.

App Development (SharePoint 2013):

· When developing an app select the most appropriate client API:

o 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.

o 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.

o Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.

o Windows phone apps need to use the mobile client object model.

o If an App contains a Silverlight application, it should use the Silverlight client object model.

o Office Apps that also work with SharePoint need to use the JavaScript client object model.

Quality Assurance:

Custom code must be checked for memory leaks using SPDisposeCheck.

False positives should be identified and commented.

Code should be carefully reviewed and checked. As a starting point use this code review checklist (and provide additional review as needed).
Provide an Installation Guide which contains the following items (Note this relates to SharePoint Deployment Standards):

Solution name and version number.
Targeted environments for installation.
Software and hardware Prerequisites: explicitly describes what is all needed updates, activities, configurations, packages, etc. that should be installed or performed before the package installation.
Deployment steps: Detailed steps to deploy or retract the package.
Deployment validation: How to validate that the package is deployed successfully.
Describe all impacted scopes in the deployment environment and the type of impact.

Branding:

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 behavior, 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.

Deployment:

All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.
Do not deploy directly into the SharePointRoot (12-Hive, 14-Hive) Folders. Instead deploy into a folder identified by Project Name.

Features:

Features 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 and Site Features may be hidden if necessary.
Ensure that all features you develop have an appropriate name, description, updated version number and icon.

SharePoint Designer:

SharePoint Designer 2007 updates are generally not allowed.

The only exception to this rule is for creating DataForm Web Parts.
The following is a recommended way of managing this aspect:
Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the .webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment 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.

SharePoint Designer 2010 updates are generally only allowed by a trained individual.

The following is a recommended way of managing the creation of DataForm Web Parts:
Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the .webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment as a feature.

SharePoint Designer workflows should not be used for Business Critical Processes.

They are not portable and cannot be packaged for solution deployment.

Exception Note: Based on the design and approach being used it may be viable in SharePoint 2010 for you to design a workflow that has more portability. This should be determined on a case by case basis as to whether it is worth the investment and is supportable in your organization.

Site Definitions:

In SharePoint 2007 site and list templates must be created through code and features (site and list definitions).

STP files are not allowed as they are not updatable.

Site definitions should use a minimal site definition with feature stapling.

Solutions:

Solutions must have a unique GUID within the farm.
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.

Source Control:

All source code must be under a proper source control (like TFS or SVN).
All internal builds must have proper labels on source control.
All releases have proper labels on source control.

InfoPath:

If an InfoPath Form has a code behind file or requires full trust then it must be packaged as a solution and deployed through Central Administration.
If an InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form.

Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

WebParts

All WebParts should have a title, a description, and an icon.

Application Configuration

· There 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.

o 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.

o 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 http://pbs2010.codeplex.com/

o 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 http://spconfigstore.codeplex.com/

o 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 http://features.codeplex.com/. This feature only stores values in the Web Application. You can build a hierarchy of persisted objects but these objects don’t necessarily map to SPSites and SPWebs.

Rajshekar Indoori -Sharepoint , O365 ,AZURE , Devops, Snowflake and RPA expert