Hi, my name is Matt. I’m a senior developer at Metalogix. This post gives you a preview of what we’re doing to embrace PowerShell in our applications. It’s an initiative that we’re quite excited about, and we would like to know what you think.
Custom Drives
The new Metalogix application framework (version 4.0) provides a custom PowerShell drive for accessing SharePoint via our connectors. These function as a command-line analog to adding a connection to our Explorer view, using PowerShell's custom provider mechanisms. Creating the custom drive is easy. Once you've added the Metalogix snap-ins, you simply use the new-psdrive cmdlet provided by Microsoft and specify MetalogixSharePointProvider as the psprovider like so:
new-psdrive -name <name> -root <SharePoint URL> -psprovider MetalogixSharePointProvider
Once connected, you can navigate SharePoint just like you'd navigate a file system, using familiar commands like dir and cd. You can browse your sites, lists, folders and items, all from the command shell. At this point, anyone who has worked with SharePoint in PowerShell will be wondering why they should use our provider, rather than simply accessing the SharePoint object model directly. Our connector provides two key advantages over standard OM access. Firstly, our connections are more lightweight; they use far less memory to hold handles on the same objects. Secondly, our connectors seamlessly allow connection to remote SharePoint instances, without requiring the use of PowerShell’s remote capabilities. This empowers users to work against SharePoint in PowerShell without mandating as heavy a permissions set.
Cmdlets
Navigation is useful, but my favourite thing about the custom drive is that it allows easy use of the cmdlets we've developed to go with it. After all, what good is looking around if you can’t actually do anything with what you see? To this end we’ve added a few basic cmdlets for our SharePoint actions that do things like get different SharePoint objects, create them, and copy them. There’s also a cmdlet for search. By the time we release our PowerShell integration pieces out into the wild, there will be cmdlets for just about anything you’d want to do in our context menus. Combining these cmdlets allows us to create some pretty powerful PowerShell “one-liners,” like this:
search-sharepointsite -target (get-sharepointsite http://intranet/sites/target) -includedocuments -author Matt | copy-sharepointitem -copyversions -target (get-sharepointlist http://intranet2/demo/testing PSA)
That’s pretty specific, but that command will search the SharePoint site at http://intranet/sites/target, get every document authored by anyone with Matt in his name, and copy them along with their versions to the library named PSA in the site at http://intranet2/demo/testing.
My favourite application is a script I wrote to do incremental document copying. Why do I like it so much? Because with a wee bit of trickery, Windows scheduler will run PowerShell scripts! So we can schedule this script to run nightly and use it to push document changes made in a development environment out to a production environment automatically. And this is only one simple example of the kind of things we can do with PowerShell as our cmdlet vocabulary gets more complex.
GUI Integration
Alright, at this point you’re probably saying to yourself that that’s all well and good, but I wrote the cmdlets, the PowerShell drive stuff, and the underlying framework, so of course I can write a script like that. If an average user who is used to just pointing and clicking in our application wanted to do something like that, the learning curve for using PowerShell and our cmdlets could be a bit discouraging. Fear not, for we have anticipated that issue . To take care of it, we have provided an easy way to generate scripts. And it comes with screenshots!
Just set up your job, right click it and choose “Generate PowerShell Script.”
Up pops Notepad with a script that will perform that job.
While this script may look intimidating, a lot of the more verbose and complicated parts are caused by using the most generic approach possible inside the automatic script generation, which introduces additional complexity. If you were intending to write a script to perform the same task by hand, you could do something much simpler using the Get cmdlets or navigating to the SharePoint objects you want to work with using the custom drive. But this is meant to be a generic job script with some action-specific logic to do the work. Just give it a name and save it as a .ps1 or .ps2 file and you can run it from PowerShell.
There is still work to be done increasing our set of cmdlets, but the framework is in place. We plan to quickly expand the ways we can empower users of Metalogix products with this powerful new tool.
Matt