Getting to grips with PowerShell

In the fifth part of his SharePoint 2010 odyssey, Robert Schifreen learns the importance and baroque style of PowerShell.

If you thought that SharePoint was difficult to learn, you have never encountered PowerShell. It's the old DOS command line on steroids. You'll probably want to be on something even stronger after your first encounter with it, as there are more than 500 SharePoint-specific commands alone, and it's a hugely powerful scripting language.

Although you can do all your SharePoint admin through the web interface via something called Central Administration, getting to grips with doing things in PowerShell is well worth the investment in time.

For example, instead of sitting in Central Admin creating dozens of departmental site areas, you can take a CSV file of your department names and quickly turn it into a PowerShell script that does the job for you. If the resulting site structure then doesn't look quite right, just alter the script, delete all the sites you created (using PowerShell, naturally), and run the script again.

Becoming an expert in Microsoft products is an endless path. By the time you know it all, the product will be obsolete.

So being a good SharePoint admin means learning SharePoint and PowerShell. That's just the start. You'll need to know SQL Server too, because that's where SharePoint stores almost all of its content. And Windows Server, in order to tweak SharePoint's performance. And IIS, in order to tune the websites that SharePoint creates (and to manage some things that it doesn't, like SSL certificates).

Buy just one decent book on each of those topics and you're looking at around 3,000 pages of material to digest in addition to actually finding time to build a working portal. 

If you want enterprise-level search, or want to do some branding/skinning work, or create workflows or web parts (portlets), you can safely double that figure to include books on FAST, InfoPath, Business Intelligence connectivity services, Visual Studio, SharePoint Designer, and more.

Becoming an expert in Microsoft products is an endless path. By the time you know it all, the product will be obsolete. And yes, thank you, I do know that SharePoint 2013 is due out in beta soon. And that SQL Server 2012 has just come out. And that Windows 8 Server is due real soon now, too.

User profile pictures

SharePoint can display users' mugshots, both to the user himself and to anyone who looks up that user in the system. However, for a product that is on its 14th incarnation, the process is not exactly straightforward or efficient.

As with AD, SharePoint has its own photo store rather than being able to directly access mugshots from AD on the fly. Assuming the photos exist in AD, there are facilities to sync them with SharePoint. In our case, though, our pictures of staff and students aren't stored in AD but within an Oracle database that's part of our student information system. It was time to dig out PowerShell again.

Each SharePoint user profile entry has a PictureURL field, which specifies the location of the user's image. That's fine if your pictures are on a web server, but more fiddly if they're in a database. I wrote a PowerShell script that sets each picture URL to sharepoint.brighton.ac.uk/image.php?un=xxx, where xxx is the user's username.

The image.php code, which I also wrote, then pulls the picture from Oracle and sends the data to SharePoint in the size that it is expecting. SharePoint has no idea that the image data is coming from Oracle rather than from a local JPG file.

SharePoint expects to be able to request three sizes of picture, depending on the type of page upon which it's being displayed. By having my PHP code do the resizing, and by pulling the pictures from Oracle, it saves having to fill a SharePoint database with three pictures for each of our users. It does, though, mean that we needed to add a small dedicated PHP server to the SharePoint constellation, but this will almost certainly come in useful for other 'helper' processes and interfaces in the future.

Having PHP code that pulls pictures from Oracle, rather than storing pictures in SharePoint, will also give us additional flexibility. For example, anyone who doesn't want their picture to be publicly viewable could have a flag set in our LDAP database that my code, and any other internal university system, could obey.

With these challenges overcome, an even bigger decision awaited. And it had to do with BLOBs. 

Next: Attack Of The BLOBs

Robert Schifreen has reported on and implemented online technology since the early 1980s. His latest project has been a large SharePoint 2010 installation in tertiary education. We will be serialising his experiences, positive and negative, in getting it to the stage where it's ready for action; the entire series will also be available as a downloadable white paper.