Showing posts with label SharePoint Online. Show all posts
Showing posts with label SharePoint Online. Show all posts

Sunday 23 February 2014

SharePoint Online Random Tips

1.> SPO and PowerShell:
To connect and use SharePoint online you cannot have a small business plan (P).  The Medium and enterprise Office 365 plans allow the SPO PowerShell scripts to run (very few so far).
Steps to use PS against SPO:
1.1.> Download and install the SharePoint Online Management Plugin
 1.2.> Add the snap-in/module to your PowerShell (or use the console with the snap-in already loaded)
 1.3.> Connect to your SharePoint site and validate it works.

=============================================================

2.> OOTB SPO Workflows:
P Plan only has three state workflow
E Plan has 5 basic workflows: signature, 3 state, approval, ..

Sandbox does not support Visual Studio based (code) workflows but you can create declaritive workflows via SPD.

SharePoint 365 Workflow Creation Process:
  • Prototype in Visio 2010 by using the SharePoint specific workflow, this can be demonstrated with the end user as they understand Visio workflow diagrams to explain there business process.
  • Export Visio 2010 diagram to SPD
  • Implement the workflow using SPD can integrate InfoPath forms
  • Custom actions are created using VS and can be deployed, the custom actions can be integrated into the SPD created workflow.
=============================================================

Thursday 24 February 2011

SharePoint Online Beta primer for developers

Overview: The development API is based on SharePoint 2010 server side object model so it's robust, flexible subset of SharePoint 2010 on-premises editions.
  • You obviously can configuration SharePoint Online using your browser, or SharePoint Designer 2010·
  • You can use VS 2010 to write custom code and this is what i am interested in.
  • My understanding is that SharePoint developers should have an easy path to SharePoint Online development.
  • For a test environment you will have the same API that is available as a sandboxed solution on the on premises version depending on licencing selected.
  • Your local SharePoint 2010 development environment is where you will write code that will be uploaded to SharePoint online via a solution package.
  • You will be able to intelletrace (VS universal and debugging) on the uploaded code in production.
  • Development teams will find it alot easier to develop locally and then deploy the finalised code.
  • Custom code can either be deployed in a sandbox solutions or a custom application can be written that will make use of the Client Object Models (Silverlight, .Net framework or ECMA Script)
  • Sandbox custom code is deployed through SharePoint solutions (wsp packages)
  • You won't have access to deploy Full trust proxies so this means functionality that you usually write as FullTrustProxies will not be available. A common example is logging to the ULS. Similarly you won't be able to log to your own custom logging system unless you offer an accessible interface that can be called from the sandboxed code.
This post is based on the SharePoint Online Developer Overview beta documentation.

Update: 25/02/2011 - Steve Fox wrote this recently for SharePointPro Connections, "What Will it Be Like to Develop for SharePoint Online?"

How is SharePoint selling - a consultancy services roadmap

Overview: SharePoint is being taken up very quickly but it's a difficult market to measure.  A figure I heard at a conference a few months ago is that for every $1 spent on licencing generates $6 in consultancy.  I don't know this ratio was determined but if the number of licences being sold is on the up, it follows there will be a great deal of consulting services needed.

Most organisations I have dealt with use SharePoint to a very limited extent.  It has a lot more to offer than clients are taking up.  Intranets, file server replacement and collaboration are the main impetus for using SharePoint.  My feeling especially with SharePoint 2010 will be a shift toward better integration and using SP as a development platform.  Office 365 plays into this consultancy business also.  The main issue will be with setup/on site installations taking a hit however there still will be a need on site installations but more companies will choose SharePoint as a service and this is only a positive that results in more people taking to the product.

The companies affected will be the hosting companies as they will loose a lot of there sales, Azure will also affect them.  They have been loyal customers of MS for years and unless they change their offering to be more consultancy service based they will take a huge hit.

Anyway some quotes to show how SharePoint is selling:

"SharePoint licenses have surpassed the 100-million mark and more than 17,000 customers use SharePoint." Microsoft Technet 9 Feb 2011.

"Microsoft’s fastest selling server based product" is a phrase often banded about not sure what this metric is but it sounds good.

References:
http://blogs.technet.com/b/office_sustained_engineering/archive/2011/02/09/1office-2010-and-sharepoint-2010-momentum-amp-service-pack-1-update.aspx

Monday 21 February 2011

Mapping internal users (LDAP) to the cloud

Overview: Steve Plank has a great video on "How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud". 

To get your internal ADFS users to authenticate in the Microsoft cloud (Azure and Office 365), you do need ADFS 2.0.  The claims based authentication that can be setup in SharePoint 2010 is how Office 365 and AZURE will authenticate AD users. 

You users will access SP2010/MS Online365/AZURE Web application using their browser.  The end application sends the browser a response redirecting them to the MS Federation Gateway (MFG)/App Fabric/STS web service (SP2010 on site editions), this in turn passes the users browser onto ADFS.

ADFS generates the user a SAML token and the are redirected to the MFG, MFG in turn generates it's own SAML token containing it's claims and the browser is redirect back to the originally requested web application.

For a user trying to access SharePoint Online from their internal network, you can see the user makes several requests to different points along the chain however the key result being the user get securely authenticated against you internal Active Directory (AD).
Steve Planks video is easier to follow than this post but it's worth understanding the process as it applies to Azure, SharePoint claims based authentication and Office 365.  This coupled with custom LDAP providers results in a consistent manner to handle authentication in the cloud using you internal LDAP directory.

Below is an animation describing the process whereby a user is authenticated on their internal network and then they use SharePoint Online (Office 365).
More Info:
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx?wa=wsignin1.0

Settingup ADFS for SharePoint Reference: