RC2 Update for SharePoint PSProvider

No changes. Too busy at work. Argh. However, it now works with PS RC2. Argh.

(old binary removed) - latest version always at:

I'm also trying to finish off zip, gzip, tar and bzip2 cmdlets along with an experimental tar/zip provider. Stay tuned, if you've got nothing better to do and a few months to spare. Honestly though, I hope to finish them before the end of the month. There's a warm bed waiting for them up on the CodePlex I'm told...

WSS v3 and SharePoint Server 2007 SDKs released

Just released SharePoint SDKs; these look quite meaty -- The wss one weights in at nearly 34MB, compressed.

Windows SharePoint Services V3: SDK

This SDK contains conceptual overviews, programming tasks, samples, and references to guide you in developing solutions based on Microsoft® Windows® SharePoint® Services (version 3).
SharePoint Server 2007: SDK

The Microsoft Office SharePoint Server 2007 (Beta) SDK contains conceptual overviews, programming tasks, code samples, and references to guide you in developing solutions based on Microsoft® Office SharePoint® Server 2007.

I've also just installed the fresh Beta 2 releases on a virtual machine, so I'll be looking forward to porting my PowerShell SharePoint provider to v3...

RC1 Refresh Update for SharePoint Provider

Hmm, I just realised that RC1 and RC1 Refresh have different build numbers and are not binary compatible. Here's another drop built for rc1 refresh, 1.0.9567.0:

(old binary removed) - latest version always at:

Would anyone like to see how to make a provider?

I've got the bones of a Compressed Folder (think zip files) provider lying around, and I was wondering if people would be interested to see a blog entry on how to put it together? I think I need a bit of a break from the SharePoint provider, so I'd be happy to write up a two-parter on how to get it up and running. Everyone seems obsessed with cmdlets; has anyone else got the psprovider bug, or is the learning curve too steep/documentation too confusing?

SharePoint Provider 0.5 - PowerShell / RC1 Compatible

Just some minor fixes, and the obvious API changes needed to be RC1 compatible. Source has been pushed the the MSH Community Extensions Workspace. For those of you who just want to play, you can get the latest binary at the bottom of this entry. Installation has changed slightly:

PS c:\temp> InstallUtil Nivot.PowerShell.SharePoint.dll
PS c:\temp> Add-PSSnapin Nivot.PowerShell.SharePoint
PS c:\temp> New-PSDrive wss SharePoint
PS c:\temp> cd wss:
PS wss:\>

Apart from some minor refactoring, I've added some more actions to allow copy/move/delete between users/roles/groups and webs. Here's an example of how easy it is to define the operations for adding and removing users to a SPWeb using my generics-based provider model:

// add SPUser and place in Reader role by default
    new Action<IStoreItem>(
        delegate(IStoreItem item) {
            SPUser user = (SPUser)item.NativeObject;

// remove SPUser
    new Action<IStoreItem>(
        delegate(IStoreItem item) {
            SPUser user = (SPUser)item.NativeObject;

The above code allows the following to work:

   PS wss:\subweb> copy ..\!roles\contributor\username .

where . represents wss:\subweb, an SPWeb object.

Have fun!

Build RC1 Only, NOT RC1 Refresh -- for latest version see homepage 
Download: Nivot.PowerShell.SharePoint-0.51.zip (40.94 KB)

(edit: minor bug found -- v0.51 update)

Monad RC1 Released - Renamed "PowerShell"

Well, one sign that we're close to a release -- they've let the marketing monkeys out of their boxes for the day. What's the first stinky poop thrown from the cage? the name change: "powershell." I find all this kind of self-congratulatory naming very indulgent or something. I imagine the ultimate extension of this to be renaming a country to "WE ROCK."

I find it hard to believe that the richest company in the world can send a dozen highly paid marketeers into a room with their free soda and the best they can come up with is the "power" prefix. Anyhow, perhaps it fits in with the "powertoys" brand or something. Another thing that makes it seem a bad choice is that there are already several "powershell" products out there in the world. Not to mention "powerdiets," "powershoes," and no doubt several varieties of "power-pants."

Man, I'm spending too much time on this non-issue already. I'm starting to feel psychotic... go grab yerselves a new shell already.



Life intervenes...

I wish I could say I'm busy working on my SharePoint provider, but eh, no. I'm currently embroiled in the living hell that is house hunting: mortages, loans, notaries, agents and other such savagery. Why can't I just buy the friggin' thing on eBay? Oh yeah, just remembered why: you would pay $400,000; get hit by PayPal for $50,000; it would be the wrong colour; it would be late; the seller would insist on you paying via Western Union before shipping you a garden shed. etc etc.


Msh / Monad Provider for SharePoint 0.4 Source

...released to GotDotNet's MSH Community Extensions run by Monad MVP Blogger, Keith Hill.

Monad / Msh SharePoint Provider Release 0.4

So, another drop for you today:

It now supports infinitely complex paths, and copy/move/delete:
     # clear all alerts for the 'username' found in the contributor role
   remove-item wss:\site\subsite\!roles\contributor\username\!alerts\*
   # make the cross-site group 'crosssitegroup' part of the administrator role
   copy !groups\crosssitegroup  !roles\administrator\
   # upgrade perms for 'crosssitegroup' from reader to contributor
     move !roles\reader\crosssitegroup !roles\contributor
Of course, wildcards work too, so let loose!
pseudo containers (will tab complete, but not show up in get-childitems):
   !alerts, !groups, !roles, !lists, !users
When in the context of certain containers, only a subset of these will appear. For example, when in the user container, only !groups and !alerts are available
   user, group, role, list
  alert, listitem
I've implemented a handful of what I call "adders" and "removers" to allow basic copy/move/delete functionality between different types of compatible (and incompatible) paths. So, what do I mean by "incompatible?" For example, it is currently possible to do:
   move-item \!users\oisin \!roles\contributor\
So, what happens is the user oisin gets copied to the contributor role (ok) and then is removed from the source (not ok). In sharepoint terms, this makes oisin a contributor, and then removes him from the site users -- which also removes him from contributors :)
Since I plan to release the source when I get to a reasonable beta level, I don't want any dirty hacks. I'm taking the time to architect the copy/move/remove path rules properly, so as to give back a solid, reusable framework to the community.
Use with:
   installutil.exe nivot.monad.sharepoint.dll
   add-mshsnapin nivot.monad.sharepoint
   new-drive <drivename> sharepoint <url>    ( e.g. new-drive wss: sharepoint http://localhost/ )

(old binary removed) - latest version always at:

Monad / Msh SharePoint Provider 0.3

Update April 8th: for latest version -- see home page http://www.nivot.org/

This was a lot of pain; but through a combination of Lutz Roeder's Reflector, MDBG and tinkering, I've got a functioning NavigableCmdletProvider derived SharePoint provider working:

  • only supports Drive-Qualified operation at the moment
  • no support for copy,delete or move, yet.
  • each web exposes pseudo container paths of !Alerts, !Groups, !Lists, !Roles, !Users
  • no format-types xml included yet, so directory display is a little messy

This initial release only supports running on the same server as sharepoint, meaning you'll need to install 2.0 framework and Monad 3.1 onto your sharepoint box. Just extract the DLL and run the following commands to get started:

MSH C:\Monad\Snapins> c:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe MshSharePointProviderSnapin.dll
MSH C:\Monad\Snapins> add-mshsnapin nivot.monad.providers
MSH C:\Monad\Snapins> new-drive wss sharepoint
MSH C:\Monad\Snapins> cd wss:
MSH wss:\>

So, from here you can use cd or set-location and hit tab to cycle through the pseudo containers and subwebs. Once inside, e.g. wss:\subsite\!roles, you can type dir to enumerate all SPRole items. Alerts, Groups, Lists, Roles and Users are treated as containers. Alert, Group, List, Role and User are leaf nodes. I'm extending this to treat a List and a User as a container too to expose their collections (List.Items) and (User.Alerts) as further containers. Currently, only simple paths are supported, some examples:


Complex nested paths will be in the next release, e.g.


Currently, it does support not SPS; you can map a drive to the root of a portal, but you will experience some weird behaviour. I plan to incorporate support for that in the future.

The next release will support copy, move and delete semantics between containers. It will also support complex paths. Post any ideas, feature requests and/or anything you feel might a bug or just done wrong. I'm working on a list of concrete features for my next post.

Have fun!

( for latest version, see homepage )

About the author

Irish, PowerShell MVP, .NET/ASP.NET/SharePoint Developer, Budding Architect. Developer. Montrealer. Opinionated. Montreal, Quebec.

Month List

Page List