Real World SharePoint 2010

Real World SharePoint 2010 - Indispensable Experiences from 22 MVPs

I had the opportunity to contribute to this amazing project, Real World SharePoint 2010 – Indispensable Experiences from 22 MVPs, now published by Wrox (

The book is a sort of anthology, made up of several indipendent, although related topics about SharePoint 2010: workflows, BCS, authentication, management, client and server development.

I wrote, together with my friend and colleague Igor Macori, the chapter about to Digital Assets Management: it covers both administration and development tasks, and it is aimed at providing an overview of the main aspects you should consider while analyzing and defining a DAM solution.

Take a look, you’re going to find somenthing interesting and, I hope, even something fun 🙂

Managing IIS settings through PowerShell

Do you miss the IISAPP command line tool that was available with IIS6?

Do you feel that APPCMD is not enough?

Enter the WebAdministration PowerShell module!

Its usage is straightforward, as it it leverages the concept of providers and drives that the PowerShell engine uses to unify the way you access resources on your server. And it provides several commandlets that can help you automate most (if not all) of the web administration tasks.

In order to use the WebAdministration module, you need to launch PowerShell with elevated rights, then just import the module:

Import-Module WebAdministration

A quick Get-Command will show you that there’s something to try!

gcm -Module WebAdministration | Measure-Object

In my environment, this shows a total count of 74 items (71 commandlets, 2 aliases and one function).

I’ll let you explore the list of commandlets yourself, while I spend some other words about the function, whose name is “IIS:”.

Just like C:, D: etc, which are indeed just functions that set the current location to the root of the C or D drives, the IIS: function uses the Set-Location commandlet to “move” to the IIS: drive.

Which, of course, is not a drive based on the FileSystem provider, but is relies on the WebAdministration PowerShell provider that you get inside the WebAdministration module.

Thanks to this approach, you can easily “navigate” within IIS settings just by using “dir” or “cd” (which, btw, are aliases too). For examples, if you need to list the IIS Web Sites on the local server, just try with this syntax:

dir IIS:\Sites

Or if you need to get, say, the list of running w3wp.exe processes for a specific application pool, you can type something like this:

dir IIS:\AppPools\<NameOfTheAppPool>\WorkerProcesses

Nice, isn’t it?

PowerShell string escaping

Ok, this is probably a very very basic topic to tal about, but anyway…

String escaping has always been cumbersome and tricky in – I guess – most of the programming languages I have used. You need a way to represent special characters, most of the times you do this by defining them through an escape sequence, and most of the times the escape sequence is made up of an escape character followed by another character (or a character code). You know that \n stands for “newline” in ANSI C syntax, right?

PowerShell follows these widely adopted standards, with a couple of gotchas.

First off, the escape character is the backtick (`), which is 0x60 (96) ASCII code and the U+0060 Unicode code.

Which is fine, I mean, using a backslach or a backtick… it doesn’t matter.

Well, yes, it does’t matter, although I’m using the Italian keyboard layout and we have no grave accent (back tick) character anywhere. Sgrunf 🙁

Second: in PowerShell we can use both single quote and double quote characters to enclose string literals.

The difference stands in the way the string is interpreted before being used.

Consider, as an example, the MSSQL$SHAREPOINT string.

If you use single quotes (‘MSSQL$SHAREPOINT’), you get exactly what you have typed within the single quotes.

If you use double quotes, and try to print-out the string variable:


You get, guess what, just MSSQL on your output stream.

The reason for this behavior is due to the automatic variable substitution that the PowerShell intepreter performs and strings literals escaped by double quotes: variable names, in PowerShell, are prefixed by the $ char, which means that the previous string is resolved as MSSQL concatenated with the value of the SHAREPOINT variable, which in my case is just null.

Sometimes, even simple things get tricky!