Emailing a SharePoint Group from Flow, part 2: The custom connector

In Part One of this blog I showed how email all users from a SharePoint group using Microsoft Flow. In part two I’ll show how to reuse this Flow from other Flows using a Custom Connector.

The “Email a SharePoint Group” Flow from part one is a standalone Flow that does one thing – emailing the SharePoint group. It’s invoked via an HTTP trigger, which means that to consume it from another Flow, you need to wire up a Request action with the appropriate URL and POST data. This isn’t ideal for two reasons: It requires knowing the arcane details of the endpoint and how to set it up in a Flow, and it necessitates exposing the endpoint URL to anyone needing to use it from a Flow.

In this blog we’ll abstract away the details of that action by wrapping it in a Custom Connector.

In other words, we’re going to go from this:

to this:

What you’ll need

In order to follow along you’ll need the following:
1. The Flow you created in Part One
2. Postman (you can download it here: https://www.getpostman.com/

Creating the Custom Connector

There are a couple different ways to generate a Custom Connector for Flow. We’ll use a Postman collection to help us generate the API definition that Flow needs to set up the connector.

We’ll use the following data as the inputs for our Postman collection. Remember, our Flow is onvoked via HTTP request to: https://prod-23.westus.logic.azure.com:443/workflows/0184591fa2bd4547b5ed01046cb51d18/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=qdPtgtY0Rn8vBAYNBLeISLh_I2s1etjWw7QrOZ_TO8Q

POST Body:

{
"siteUrl": "https://mytenant.sharepoint.com/sites/Home",
"groupName": "Home Members"
}

I won’t go into detail about how to create a Postman collection, (you can read about it here), but in a nutshell you’ll want to set up your POST request to your Flow URL and add the JSON to the body. Don’t forget to set the Content-Type to application/json, and choose to export a V1 collection version.

Once you’ve exported the collection, you’ll be ready to move into Flow and set up the custom connector.

Setting up the Custom Connector

In Flow, click the gear icon in the top bar and select “Custom Connectors”, then “Create Custom Connector” and select “Import a Postman Collection”.

Once the collection imports, you’ll see a four-step wizard where you’ll configure your connector.

In step 1, General, you have options to change the default color and logo. You can accept the defaults or set a custom look for the connector. We’ll stick with the defaults here.

In step 2, Authentication Type, leave the default at “No Authentication”

Step 3, Definition, is the most involved. Here you can tweak your actions and add new ones. We’ll have one action already defined, and you’ll see the four query string parameters passed into the POST request. We’ll want to hide these from the Flow author, so we’ll click on each one, select “Edit”, and set its visibility to “Internal”

Step 4, Test, will require we click the “Create Connector” button and actually consume the connector. We should see all our parameters, and if we add an appropriate POST body and click “Test Operation”, we should get a 202 response back. Also we should see that our souce Flow was triggered and ran successfully.

Create the Flow

Now we’re ready to create our Flow and consume the custom connector. Here I’ll just create a Button-triggered Flow and search my actions using the word “Email”. You’ll see I got two custom connectors back because I created two of them in my dev sandbox.

When you configure the action it’ll prompt you for a site url and a group name where the email will be sent. If I had set the visibility of the Content-Type parameter to “Hidden” that would have been gone from the interface as well.

Now you have a custom connector that you can re-use in all your flows to email any SharePoint group in any site your Flow author has access to. You also have a pattern for creating sub-Flows and a way to execute them in a scalable manner.

Homework

Try to create your own custom connector to email a SharePoint group. Pass the subject line and email body as parameters. Let me know how it went in the comments.

Scheduled Item Publishing in Modern SharePoint Site Pages

For those of us used to the rich content publishing features in the old “Classic” SharePoint Publishing model, the new Modern experience takes a little getting used to. For example, until very recently there wasn’t much at all in the way of content approval to say nothing of the more advanced features like scheduled item publishing. This month (August 2018) Microsoft announced a new solution for page approvals utilizing Flow under the covers, which promises to enable the sort of functionality we were used to in Classic publishing sites.

One of the Classic features my client use all the time is scheduled item publishing. In Classic Publishing libraries, this was a setting on the library that allowed content approvers to set a date and time when the page would be published, and it worked pretty well. This feature is missing on Modern, but with the new Flow capability, we can bring it back.

Enabling the Approval Flow

On the Modern Site Pages library, in the Flow dropdown, we not have the option “Configure Page Approval Flow”.

If we choose the option to do this we get a slide out panel that allows us to set up our list of approvers.

Now, once we’ve done this, we get the option to “Submit For Approval”. Clicking this option opens an initiation form where we can kick off the approval process. The users specified in the flow configuration will get the Approval email, and on approval the page will get published.

Updating the Flow to support scheduled item publishing

To enable scheduled item publishing we need to do two things. First, we need a way to specify the date on which we want to publish. An easy way to do this is to add a Date field onto the Site Pages library. Use a custom content type that inerits from Site Page add this field there.

The second thing we need to do is modify the Flow to add a “Delay Until” action, using the Date field we added to our content type. We’ll put this inside the “Yes” branch of the condition that follows the approval result. It looks something like this:

Now, when we submit a page for approval, we can see the Flow waiting until the publish date and time before proceeding on to publish the page.

Some things to be aware of

All in all, this process works pretty well, but the whole Approval Flow business has some rough edges, and some things that don’t quite work as well as they should.

There’s no way to see configured Approval Flows for a library.

SharePoint will happily allow you to configure many approval Flows on a single library, because the UI has no way to show you the Flow(s) that have already been configured. Unless there’s a way I’m not aware of, the only way to see your approval Flow is to go directly to Flow and pick your Flow from the list. Which can be a problem, especially considering…

Flows don’t scale well.

If you have 200 sites, you’ll need to configure 200 separate instances of the Approval Flow. Obviously this is a governance and maintenance nightmare, and woe be upon the person who has to do all this grunt work, because Flow creation is not easily automated. One possibility might be to create a master Flow that all the other Flows call via HTTP request, and simply update each Approval Flow to launch that.

You’re stuck naming individual people as approvers, no SharePoint or AD groups

The UI doesn’t allow for this, but the approval email actions don’t allow this, so I think that’s the cause of the limitation. We can do a little more work inside the Flow to fetch a SharePoint group but that’s maybe a topic for another time.

Flows crap out after 30 days

If 30 days transpire after the invocation of a Flow, the Flow will just stop working. This seems to be a hard limit. So when submitting your Approval Flows, be aware of this limitation.

Wrapping it up

SharePoint’s Modern initiative replaced a mature, battle-hardened system in Classic Publishing, and naturally there would be some functionality gaps to close. Microsoft is working quickly to address this, and it seems reasonable to expect further evelopments along this path. For now, at least we now have a way to deliver scheduled item publishing to our clients in Modern SharePoint.

Copy Link in Modern SharePoint – non-obvious security implications you should know about

Recently I encountered a strange issue in a client’s Intranet during the content buildout phase. They’d given read-only access to a group of pilot users, and loaded up their site with pages and links to documents. Then they began to notice that these pilot users appeared to have the ability to delete the documents, and logged a bug with us.

We discovered that the document library had hundreds of files with broken permission inheritance, and that the Everyone principal had been granted Contribute permission on each one of these documents, meaning they could edit and even delete the documents.

Thinking that some rogue user had inadvertently (or “advertently”) shared those documents in error, we ran a script that looped through all the documents in each library and restored the permission inheritance on each one. Then we discovered that the several hundred or so hyperlinks to the documents throughout the system began returning 404s.

Eventually we tracked the issue down to a “feature” of the Copy Link action bar item in Modern SharePoint document libraries. We discovered that Copy Link does a bit more than merely return a link to the document to the user’s clipboard.

My client had been using SharePoint’s Copy Link functionality to create those links, just as we had taught them to. But what we didn’t realize was that clicking Copy Link was actually breaking the security inheritance on the document, and sharing it to the entire company. This was because the tenant settings that drove this functionality were left in their default settings, which inexplicably default to the most permissive – the most insecure – setting.

Check out what happens when you click the button:

Once you see this dialog, permission inheritance has already been broken and the permission “Anyone with the link can edit” has already been applied. If you select another option, the permission will update – even to the point of reinstating permission inheritance if “People With Existing Access” is selected. Also, the link regenerates, and previously generated links become stale and return 404s.

The link structure will tell the sharing story

If a Copy Link operation results in broken inheritance, it will look different from a link that does not.

A Sharing Link looks like this:
https://m365x692092.sharepoint.com/:w:/g/Ea90HDWefS1BnLLgtVkMNJgBdpUI6LiBC7Kw4pj0g-CIAQ?e=troe2t

..while a non-shared link will look like this:
https://m365x692092.sharepoint.com/:w:/r/Shared%20Documents/CAS/Marketing%20Strategy%20Future.docx?d=w351c74af7d9e412d9cb2e0b5590c3498&csf=1&e=TWfoVC

Note that a sharing link shows the tenant followed by a long string of crap, and the non-sharing link, while also containing its share of trailing junk, also seems to incorporate a physical path as part of its structure. So using this pattern you should be able to tell if a Copy Link resulted in broken inheritance.

My thoughts on this

You have some options for setting the default behavior of this function, but like I said the default default is the most permissive. The decision to have it behave this way vexes me somewhat. In previous versions of SharePoint it’s been difficult and tedious to break permission inheritance through the UI, and I think it ought to be that way. Breaking inheritance should only be done with serious consideration as it’s difficult to support and also has performance implications – a Microsoft employee once told me that breaking inheritance “makes SQL cry”. Maybe in the cloud we care less about performance implications because all that stuff is abstracted away. But it’s still there and I’d have to believe Microsoft cares about its servers. Anyway…

Know your tenant settings

We can manage the tenant-wide default behavior for Copy Link by navigating directly to https://-admin.sharepoint.com/_layouts/15/online/ExternalSharing.aspx

There are a number of settings related to Sharing on this page but the ones we care about are under the headings “Default Link Type” and “Default Link Permission”. The defaults look like this.

Note that in the Copy Link dialog we had four options for how to share the link, and the tenant setting only allows for three, excluding, maddeningly, the “People with Existing Access” option, the one I think should be the default. If we select the “Direct – specific people” option, though, and just not actually specify any people, the result will be the same.

The “Use shorter links” option only substitutes the “guestaccess.aspx” url with the crypic sharing url we saw earlier, nothing really to see there. The Default Link Permission setting, if set to Read, will at least limit the damage done if files are inadvertently shared to the general population.

Manipulating the settings using PowerShell

Of course these settings can be set using PowerShell at both the Tenant and Site Collection level. The Site Collection level settings will override the Tenant level settings for the site in question. Check out the documentation for Set-SPOTenant and Set-SPOSite. The options you want to look into are, on both commands, DefaultSharingLinkType and DefaultSharingLinkType. Make sure to check out the other settings related to sharing just to get a feel for how they work.

 

Remote Event Receivers – you’re all doing it wrong

Remote Event Receivers are a powerful way to integrate custom code into your SharePoint Online environment.  Essentially a Remote Event Receiver is a hook that allows you to execute your code in response to an event that occurs in SharePoint.  There are several techniques for responding to events in SharePoint Online, but the Remote Event Receiver is the most powerful. It offers dozens of different events to attach to and allows you to configure synchronously or asynchronously. It is also very easy to attach, develop, deploy, test, and maintain. Is also very misunderstood.

Remote Event Receivers were introduced along with SharePoint 2013 and the arrival of the App model. Microsoft provided tooling with Visual Studio to create Remote Event Receivers, but unfortunately the only way to expose this tooling was in the context of a Provider-Hosted App.

This is unfortunate because Remote Event Receivers have nothing to do with Provider-Hosted Apps. In order to develop a Remote Event Receiver using the Microsoft-provided tooling, a developer had to create a Provider-Hosted App project and deploy their RER along with it. This added a great deal of complexity to the development effort, and made packaging and deployment a painful and tedious experience.

To further complicate things, Microsoft decided to wire up a WCF service as the endpoint in its RER tooling. This is sheer lunacy, even back in 2013. A web API project would have been simpler and would be more in line with Microsoft development tooling efforts. The opacity and complexity of WCF made RER development even more cumbersome. Actually, I believe they decided to use the WCF service so the development experience would be similar to that of old-school Event Receivers, with the ability to use a deserialized Event Properties object.

Building a Remote Event Receiver is Easy

In truth, it is remarkably simple to configure, develop, deploy, and maintain a Remote Event Receiver, but in order to do so you must completely abandon the Microsoft tooling and just set up the pieces yourself. Luckily there are really only two components to a Remote Event Receiver:

• The endpoint
• The registration

The registration is where you tell SharePoint, “call this endpoint every time this event occurs”. The CSOM provides mechanisms for adding Remote Event Receivers, but the details depend somewhat on the type of event receiver being deployed. The  PnP PowerShell library provides the ability to register a Remote Event Receiver in a one-liner. For example, to set up an RER that is invoked every time an item is updated on a list, execute:

Add-PnPEventReceiver -List "Tasks" -Name "TasksRER" -Url https://my-rer.azurewebsites.net/Service1.svc -EventReceiverType ItemAdded -Synchronization Asynchronous

More about registering Remote Event Receivers

The endpoint is just a web service listening at a certain URL, and you have lots of options for this. A Web API project would work great for this. Azure Functions are also a very compelling option. You are also free to write services in Java, Node or whatever other technology you can think of. In the example below, we’ll use the canonical WCF Service you’d get with the Visual Studio item template, but we’re going to sidestep the template and wire things up ourselves. It’s actually easier this way.

 

Creating the Remote Event Receiver shell

In Visual Studio,

1.  create an empty ASP.NET web application
2. Add the Nuget Package ”AppForSharePointOnlineWebToolkit”.
3. Add a new item of type WCF Service to the web app.
4. Get rid of the IService reference and set your service to implement IRemoteEventService, which lives in the Microsoft.SharePoint.Client.EventReceivers namespace. This namespace came into the project with the Nuget packages we added earlier. Resolve the squiggly to implement the interface stubs.

Your service class should look something like this:

F5 your project and navigate to the service to make sure it’s accepting requests. Take note of the port number.  We’ll need that to set up our proxy for local debugging.

Locally debugging your remote event receiver

To test this event receiver locally, we’ll use ngrok. According to its documentation, “ngrok is a reverse proxy that creates a secure tunnel from a public endpoint to a locally running web service.”  We will use it to map an Internet endpoint to our local machine so we can intercept and debug requests coming from SharePoint Online.

Assuming you have installed Node.JS and ngrok, create your proxy by executing the following. 56754 is the port number hosting my local WCF service.

Once it connects it’ll output some data, including the public URL of our proxy connection:

Next, open up a browser and navigate to the ngrok URL, append the service endpoint, and you should be able to see that the ngrok URL is returning your service.

 

Next we’ll attach our event receiver to a SharePoint list. Using the PnP PowerShell cmdlet shown above, we’ll add a Remote Event Receiver to our site. Make sure to open a new PowerShell session for this and leave the ngrok session running in its window. The proxy will be released when the window is closed.

Now, set a breakpoint in your ProcessOneWayEvent method, add a task to the list and make an edit to it.  If all goes well your local web service will be called and the breakpoint will hit:

Make sure you closely inspect the properties object in the debugger, and get a feel for all the data that’s in there. For this particular event we’ll want to check out ItemEventProperties and ItemEventProperties.AfterProperties for some useful metadata that gets passed into the service.

Deploying your Remote Event Receiver to Azure

When you are ready to deploy to the Internet you can deploy to Azure just like a normal web application. You’ll want to run Add-PnPEventReceiver using the Internet URL to register your event receiver for real, of course.

 

Microsoft Flow: First Impressions

Over the last several weeks I’ve had my first experiences using Microsoft Flow in a real-world application. The client has dozens of old 2010-style SharePoint Designer workflows touching a number of business functions: Sales, Procurement, Change Management, and Human Resources, and they were looking for a way to modernize their development process and eliminate some of the quirks and irksome bugs that have been plaguing their users.  Hearing that the client was looking down the road at moving from on-premises SharePoint Server 2013 to the cloud, I recommended re-writing a number of these processes in Flow instead of SPD.

Flow is a part of Microsoft’s new cloud-based platform for process modeling, for lack of a better phrase. The idea is that non-developers can use Flow’s intuitive user interfaces to build robust integrations between their line of business applications with no code anywhere to be found.

At first glance, Flow seems to be a huge improvement over the experience of building workflows in SharePoint Designer. For starters, it’s web-based, so there’s nothing to install. Flow comes with an impressive array of standard integration points (“connectors”), a handful of entry points (“triggers”) and hundreds of pre-defined activities you can configure (“actions”).  By dragging and dropping widgets onto the control surface and setting up some basic properties, power users can create powerful applications without having to rely on developers or IT to set it up for them.

Here are a few quick takeaways from my experiences so far.

Low expectations

SharePoint Designer workflows come with so much baggage it’s difficult to imagine preferring it to any succeeding technology that comes along. So the bar here is low.

Wide range of capability

Flow’s range of out-of-the-box integration points is very impressive, and they keep adding new connectors and actions all the time. There’s even an extension model where you can create your own and submit them for inclusion in the platform.

More of a consumer focus

Many of the integration points, though, don’t seem to make a lot of sense in most enterprise scenarios. Twitter, Facebook, and Gmail are some such connectors. And many of the starter templates are more in the personal productivity realm. For example,

• Text me when I get an email from my boss
• Email me when a new item shows up in a SharePoint list
• Start a simple approval process on a document when it’s posted
• Save Tweets to an Excel file
• Send me an email reminder every day

 

Easy to extend

It’s really simple to create extension points in Flow. Suppose you have a need to do something that isn’t supported by a Flow action. If you can code, you can write an API to do what you need, and call it via an HTTP action.  Azure Functions work really well for this. In fact, the HTTP action is the most powerful thing in Flow. You can even use it to trigger other Flows from within a Flow.

Approvals are not fully baked

If you’re building approval workflows and are expecting the way SharePoint Designer works, you’ll be disappointed. An Approval in Flow consists of an email and a two buttons, nothing more. There is no concept of setting a status on an item, no functionality for logging (unless you roll it yourself), and no notion of tasks. It changes the way you think about approvals in general, because the old model just doesn’t apply here.

The Designer does not scale

For a simple two- or three-step flow, the designer works great. Add a couple of nested if/else blocks (‘conditions’), or more than a half-dozen or so actions, and you’ll find that  the design surface is totally unsuited to the task. Scroll bars are in difficult-to-find places and it’s often next to impossible to maintain your context when trying to move around within a Flow.

Sometimes saving a Flow will trigger a phantom validation error, and you’ll have to expand every one of your actions until you find the offending statement, because the Flow team have not seen fit to provide any sort of feedback on where the failure occurred. In addition, sometimes, especially when working with variables, the validation will fail even though the variable is properly configured.

No Code view

As clunky as the designer gets, if you’re a developer you might be more comfortable just coding your Flow the old fashioned way – after all, it’s just JSON under the hood. But alas, code view is not available in Flow. The design view is all you have.

Another implication of this: If you have places in your Flows where there are large blocks of similar functionality, you have no option to copy blocks of code and modify to suit. You’re stuck having to re-create those similar blocks of functionality, manually, in the designer, every single time. Believe me, this gets old really fast.

No versioning

If you make a change to your Flow and somehow break it, well, that’s tough, you’d better figure it out because there’s no rolling back.

Clearly Flow is not the magic bullet in the Enterprise process modeling world. It has is quirks and its pitfalls. But remember, the bar is low due to the legacy application it replaces.  SharePoint Designer workflows share many of the same deficiencies as Flow: a clumsy design experience (check), an inability to edit code directly (for all practical purposes), and no rollback model (technically possible in SPD via version history but janky as hell).

Given that SPD has had its ten-plus years in the limelight, and Flow is a brand-new V1 product with an engaged product team, I’d say the future looks bright for Flow.

Setting multi-valued lookups in forms with jQuery

The solution presented here can be made to work in 2007, 2010 or 2013. I’ll explain later.

Setting SharePoint form fields using jQuery is a pretty standard practice nowadays, and not too hard either. We can fetch the current user, or a value in the query string, and use it to populate form fields, saving our users from having to do it themselves.

Multi-valued lookup columns, however, are not so easy to figure out, and understanding them requires some deep DOM inspection and trial and error.

Consider the form below. It could be an edit form or a new form, it doesn’t matter. They both work in the same way.

Here I have a multi-valued lookup column called “Project Document” with a number of documents in the parent library. The form shows two large text boxes (‘unselected values’ and ‘selected values’), along with an “add” and a “remove” button to shuttle the parent list items between the two text boxes.

Now you’d think that moving the choices from one text box to the other would be enough to “set” the value in the form, but you’d be wrong. Microsoft uses hidden elements to hold the “true” values present on the form, so in order to set that value we have to update both the visible and invisible elements in the form.

Digging into the DOM

The image below shows the DOM representation of the visible elements we are concerned about. This shows a 2013 environment, but the markup is the same in 2010, at least for this part of the form.

What we see here is the two text boxes (rendered as selects) along with options, about 20 or so in the “unselected” textbox, and one, titled “SET READ ONLY DATABASE” in the “selected” text box. Notice the title attributes on these selects, “Project Document possible values” and “Project Document selected values”. We will refer to these as we “move” an option from one select to the other using jQuery.

The second part, the part SharePoint uses under the hood to actually save the lookup values, is a hidden input element located just above the visible UI we have just seen.

There are actually three hidden input controls here, but we only care about the topmost one. It does not have a handy title attribute, but it has an ID of longstringofcrap_MultiLookup. This is the place where 2010 and 2013 are slightly different. The ID is a little different in 2010. We’ll fetch the input using jQuery by using the “ends with” selector, like so:

“[id$=’MultiLookup’]” for 2013 and “[id$=’MultiLookupPicker’]” for 2010.

The hidden input that stores the actual data for the selected items does so in a peculiar, pipe-delimited format. I’ll leave it to you to soak it in and try to make sense of it:

In our function we will need to create that crazy string using the option’s text and value along with that pipe-T thingy, and add or remove it from the input’s value attribute as needed.

Putting it all together

I wanted to write a function to add a selection by name, and another function to remove a selected option, also by name. I also wanted it to be as reusable as possible, so I made the column name and value as parameters to my functions. By including these functions in a globally-referenced JavaScript file, we can use this functionality everywhere on the site. Anyway here’s the code:

//var selector = "[id$='MultiLookupPicker']"; //for 2010 or 2007
var selector = "[id$='MultiLookup']"; //for 2013

function addChoice(text, columnName) {
    $("[title='" + columnName + " possible values'] option").each(function () {
        if ($(this).text() == text) {
            $(this).appendTo($("[title='" + columnName + " selected values']"));
            var multilookupPickerVal = $(selector).val();
            if ($(selector).val() == undefined || $(selector).val().length == 0) {
                $(selector).val($(this).val() + "|t" + $(this).text());
            }
            else {
                $(selector).val(multilookupPickerVal + "|t" + $(this).val() + "|t" + $(this).text());
            }
        }
    });
}

function removeChoice(text, columnName) {
    $("[title='" + columnName + " selected values'] option").each(function () {
        if ($(this).text() == text) {
            $(this).appendTo($("[title='" + columnName + " possible values']"));
            var multilookupPickerVal = $(selector).val();
            var valToRemove = $(this).val() + "|t" + $(this).text();
            var newValue = multilookupPickerVal.replace(valToRemove, "");

            $(selector).val(newValue);
        }
    });
}

A couple of things to point out. I added two variable declarations called “selector”. Make sure only one of them is not commented out – the appropriate one for you environment. For updating the visible text boxes I am using the jQuery appendTo function, a really neat function which removes a DOM element from its current home and places it into the specified location.

Edit: Thanks to jameel’s comment below I fixed an earlier issue where I was hard coding the column name in the function. He also verified the 2010 code works for SharePoint 2007 as well.

Managing SharePoint Online with PowerShell

As a SharePoint developer and MSDN subscriber I was thrilled when Microsoft announced that it was offering a SharePoint Online subscription as part of the base benefits of an MSDN subscription.  Being able to automate administrative tasks in SharePoint Online is a big help to those of us who don’t want to click through an interface every time we need to do something.  To address this Microsoft has released the SharePoint Online Management Shell. 

Getting a SharePoint Online environment

 First, you need a SharePoint online environment.  If you are an MSDN subscriber, you already have one included in your subscription.  If not, the Developer Subscription costs $99 per year. There are also a number of Office 365 plans that include SharePoint online site. These come with a per-user monthly charge.  There are also 30-day trials available.

Installing the SharePoint Online Management Shell

Setting up the PowerShell tools for SharePoint Online is easy and only takes a couple of minutes.  You’ll need to be on PowerShell 3.0 first though.  If you’re running Windows 8 or Server 2012 you’re in luck, it’s already there.  If not it’s available for Windows 7 and Server 2008 and 2008R2 here.

Next, download the appropriate executable here, and execute it.  That’s all there is to it.

Connecting to your environment

Once the install is complete, you’ll now have a new program installed called “SharePoint Online Management Shell”.  You’ll need to launch this. Before interacting with your SharePoint environment you’ll need to connect to it, and that is done through the cmdlet connect-sposervice. This cmdlet takes a url and administrator credentials as parameters.  There are two ways you can run this.  Omitting the password will prompt you with a log in screen. To include the password, you’ll need to create a PSCredential object and pass that into the command:

$username = "admin@contoso.sharepoint.com"
$password = "password"
$cred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $userName, $(convertto-securestring $Password -asplaintext -force)
Connect-SPOService -Url http://contoso-admin.sharepoint.com -Credential $cred

(this snippet was taken straight from the Technet documentation)

It’s important to note that the url you pass in must be the  url of the administrative site, the one that looks like this:

When running Connect-SPOService, the “no news is good news” rule applies, and if it succeeds you will just see a new command prompt on the next line.

Let’s do something!

All of the available commands in SharePoint Online Management Shell have to do with creating, deleting, or maintaining site collections. To create a new site collection run the following command:

New-SPOSite -Url https://contoso.sharepoint.com/sites/accounting -Owner admin@contoso.com -StorageQuota 100 -NoWait -ResourceQuota 50 -Template STS#0

(again, code sample lifted from technet)

The full list of SharePoint Online cmdlets can be found here.

 How does it work?

Whenever you are working with tools that access remote environments, it is always illuminating to figure out the underlying technologies that make it work.  In this case I launched Fiddler and ran a few commands.  Here’s what I saw the first time:
 

That call to client.svc is the calling card of the SharePoint Client Side Object Model. It looks like the call to lists.asmx was simply to fetch a Form Digest so the CSOM call could use that to authenticate.  Subsequent commands run from the shell do not make this call, so I am guessing the Form Digest is still valid in this case.

It’s interesting to note that the ability to manage site collections is a new feature in the CSOM for 2013.  This functionality would not have been possible in 2010.

Limitations

On-Premise SharePoint PowerShell tools are quite powerful and can be used as a text-based SharePoint Manager to discover all sorts of things about your SharePoint environment.  I routinely use PowerShell to look at things like list and view schemas, field definitions, web properties, and the like.  Developers who are comfortable with using PowerShell in this fashion will find the array of commands available in SharePoint Online a little limiting.  There is no way in this tool to manage objects below the site collection level.  It appears this is strictly an administration tool.

Become a great SharePoint developer in 10 easy steps

The job market for SharePoint developers is really hot lately, and right now it’s a really nice place to be from a career perspective. There just doesn’t seem to be enough of us around, and those who are can expect to be courted quite aggressively by recruiters (at least that has been my experience). With that in mind I thought I’d put together a list of steps to becoming a great SharePoint developer and getting in on the action:

1. Be (or become) really good at solving problems. When developing SharePoint solutions, you will quite often find yourself doing things that no one has ever done before. While this is true for any type of software development(I mean, if someone else has already done it they’d just use that), it seems especially true for SharePoint development, for a number of reasons:

a. There are just not that many SharePoint developers, and the more advanced your problem the fewer people there are doing something similar;
b. The sheer size and scope of the SharePoint platform means there is lots of unexplored and undocumented territory, and every now and then you’ll search on some aspect of SharePoint and find zero hits online.
c. SharePoint rarely exists in a vacuum. There are always integration points and little quirks that are unique to the organization deploying the product. These often center around network irregularities, legacy systems, business processes, or cultural issues within the organization. Any of these points, and more, can throw wrenches into your solution.

So all these things add up to one thing: you’d better be really good at solving these issues, because there is often nowhere to turn if you can’t figure them out.

2. Have access to a SharePoint environment. And when I say “access”, I really mean a complete development farm over which you have full control. Having your own environment opens up the following opportunities:
a. The freedom to make mistakes. Software development is about “poking the box”, as Seth Godin would say. That is, you learn by trying new things, making mistakes, and drawing lessons and understanding from them. Having your own environment means you can make all the mistakes you need to, roll back and keep going.
b. Your own security sandbox. Security is an important aspect of SharePoint solutions, and you’ll need the ability to create accounts and alter the privileges of those accounts. Suppose you are building a workflow that routes to different users. Without the ability to create and use different accounts, how on earth are you going to test that workflow?

If your employer is trying to get you to learn SharePoint and they have not provided you a full SharePoint server to use, they are setting you up for an uphill and frustrating experience.

3. Get some real-world problems to solve. Real-life solutions in SharePoint are rarely as straightforward as training or demo scenarios would make it seem. It is managing those quirky idiosyncrasies peculiar to the customers’ way of doing business that separates the competent devs from the pretenders. Workflows, especially, tend to get very tricky when you try to automate real-world business processes. Hands-on labs are a great way to get introduced to a topic, but once you’ve done them, try to apply them to the way things would actually work in your environment.

4. Get to know SharePoint’s user interface really well. Smart SharePoint developers know to leverage the out-of-the-box capabilities of the platform as much as possible. This means having a firm grasp on how to use SharePoint’s various UI components properly. The Ribbon, the ECB, Site Actions, List Views, Forms, layouts pages, web parts – each of these components, and more, lend a unique aspect to the SharePoint ecosystem, and knowing when and where to deploy these items will pay off in a number of ways. For example, leveraging OOB components will simplify your development efforts and result in a more consistent experience for your users. Knowing this will also come in handy when practicing skill number 5….

5. Learn to do things the SharePoint way. SharePoint is a funny platform. In many ways it gives you a lot of freedom, but it will punish those who take too much of that freedom. I see this a lot with user interfaces. Sure, in theory you can build lots of custom web parts and user controls and layouts pages to build out your screens exactly how you want them. Just know that if you do this as a default approach you are exposing yourself to some risks:
a. You are building an unnecessarily complex solution, which will lead to bugs, maintenance overhead and place more burden on your administrators.
b. You are likely missing out on a great deal of out-of-the-box SharePoint functionality. For example, if you are building a custom solution to show a grid of data, you are losing the ECB, the Ribbon, and some nifty sorting and filtering functionality, not to mention the security trimming, which you’ll now have to manage yourself. A common List View provides all this and more, and can be quite flexible through customization.

Also included with this skill is knowing how to push back when requirements are out of line with SharePoint’s expectations. You’ll need to seize these opportunities to educate your customers on “the SharePoint Way”.

6. Find a mentor. Trying to learn SharePoint on your own is an uphill struggle, and when you hit a wall you need somewhere to turn for help. Blogs and MSDN will only get you so far, and much of the content you’ll find on the web is either not useful or downright wrong – until you figure out where to look and whom to trust. Having a mentor or a network of colleagues will be a major asset, and if you are lacking this you’ll want to look for a user group or at the very least an online community like stack exchange to bounce ideas and ask for help.

7. Learn the internals of SharePoint. While the first six traits I outlined were mostly non-technical in nature, the remaining skills will cover the technical aspects of the things a SharePoint developer needs to know. Foremost on that list is an understanding of the underpinnings of SharePoint. There is a lot to learn here, but most of it is found in the “hive”, or the file system location where SharePoint’s files live(this is known as the ’14 hive’ in SharePoint 2010). The 14 hive is a treasure trove of useful information, and by looking through it(on a development machine of course), one can learn a whole lot about how Microsoft builds things. Among the useful things you can browse in the hive include:
○ Features
○ Layout pages
○ JavaScript files
○ Site Definitions and Web Templates
○ XSLT files
○ Images
○ Configuration files
○ User controls
○ Resource files
○ Much, much more

An understanding of how SharePoint is put together will help you understand how to extend it, and will offer clues as to the right way to do things when you are stuck(which will be often).

8. Learn .NET. SharePoint heavily leverages .NET, and any non-trivial solution you build will likely involve some amount of .NET integration. Knowing how to code in .NET is crucial, of course, but of equal concern is knowing the internals of .NET. Deploying an assembly to a SharePoint farm is a complex process, and you must master the various ways to deploy and register assemblies, modify and troubleshoot configuration entries, and advanced debugging techniques.

9. Get to know the Windows Infrastructure ecosystem. I’ve said it before, SharePoint doesn’t exist all alone by itself. It is tightly integrated with several Windows products, and getting comfortable with SharePoint means getting cozy with these systems as well, including Windows Server, SQL Server, and IIS. You may optionally find yourself dealing with other players as well, including Exchange, SQL BI, and the Office client. A knowledge of WCF and Workflow Foundation will likely come into play at some point as well.

10. Build solutions, not customizations. Many people who call themselves SharePoint developers never launch Visual Studio. While it’s true you can build great solutions in a very short time without ever using Visual Studio, the benefits of that approach will diminish in the long run. These “customizations” are one-off solutions and cannot be repeated unless the work is re-done. Since there is no source code associated with these efforts, maintenance becomes a dicey affair, and when a solution is broken, there’s often no way to resurrect it.

A professional SharePoint developer will use Visual Studio to build a repeatable, deployable solution package which can be deployed and activated on a site. He will follow the same processes as a custom-code solution, with source control, testing, deployment, and support.