The UK Microsoft User Groups have organised another huge gathering at Microsoft Reading next week.

This time it's split over 2 days April 8th and 9th and features a lot of great sessions. User groups that I'm active in such as the UK SharePoint user group, PowerShell user group and the Vista squad will be there along with the user groups for Exchange, SQL Server and others.

It's not often you get a host of experts on these subjects in one location so check out the agenda and see if any sessions take your fancy.

I'm doing a session on day 2 crossing over two groups SharePoint and PowerShell on moving data in SharePoint using the Content Deployment API (aka Prime API) and PowerShell. I'll go through some of the functions and cmdlets I've written to make moving data easier, samples include moving list items, lists, webs and site collections within and between farms.

Zach Rosenfield has a nice post on calling WebServices from PowerShell. The steps are pretty simple: generate a proxy cs file, compile it into a DLL and then load that DLL up into Powershell AppDomain.

Well I've been doing some work with quite a few of the WebServices and I wanted to compile all the proxys into a single DLL.

Use Zach's post to setup the PowerShell environment variables needed to call the Visual Studio SDK utilities wsdl.exe and csc.exe

Heres the script to compile all the available SharePoint Webservice's into one DLL.

It simply enumerates all the ASMX files in the ISAPI directory and passes each item in that list to WSDL.exe which generates the proxy cs files.

You need to change the URL in this script to point to a valid SharePoint site and make sure there are no other .cs files in the directory before running this script.

$asmxlist= dir "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI" *.asmx | select name

$asmxlist | foreach-object {
write-host "Generating SharePoint Proxy Library for $($_.name)" -foregroundcolor green 

$outputfilename="FlexnetConsult.SharePoint.$($_.name).cs"
$namespace=[IO.Path]::GetFileNameWithoutExtension($_.name)

wsdl "http://portal.contoso.com/matters/sites/_vti_bin/$($_.name)" /o:$outputfilename /namespace:$namespace

}

write-host "Compiling SharePoint Proxy Library" -foregroundcolor green 
csc /t:library /out:FlexnetConsult.SharePoint.WebServices.dll *.cs 

So the output should be something like this

Now three of the WebServices generate an error SlideShow.asmx. FormserverProxy.asmx and contentareatoolboxservice.asmx but as I'm unlikely to use them I'm not going to worry about those.

So now we have a DLL called FlexnetConsult.SharePoint.WebServices.dll in our directory that we can use to call the (almost) any SharePoint Web Service.

I've attached the compiled dll and script.

In my next post I'll use the DLL to do something I've wanted to do for ages and that's list, add and delete Web Parts on a page using PowerShell.

Now your probably shouting, hey why not just call the object model and GetLimitedWebPartManager, yep but that doesn't work as without a web.config and possibly a HttpContext all you get back are Error WebParts as the WebPart safecontrollist cannot be accessed.

I forgot to post this before but Microsoft has created a virtual lab based on my blog postings. If you're interested in Powershell and SharePoint its definitely worth checking out

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032346304&EventCategory=3&culture=en-US&CountryCode=US

As noted on Ben Pierce's blog Powershell is now a CER common engineering requirement for all products released in 2009 and beyond, that should mean as Office 14 is due for release in 2009 PowerShell should be a mandatory feature in SharePoint.

Thats good news and a big change as when I'd asked the question about PowerShell support in SharePoint to Mike Fitzmaurice back in February last year the answer was they had no plan to do so.

I’m presenting at the EVO (Exchange, Vista, Office) Community day next Thursday the 21st June.

I’ll be doing a session that shows how you can use Powershell to read information from Exchange and getting it into SharePoint 2007.
Its really hard to know how to pitch a presentation like this as the mix of experiences is probably going to be wide, from people seeing this stuff for the first time to old hands. Anyway I’m looking forward to it.

The talk will cover some Powershell basics, calling the new Exchange Web Services from PowerShell and why we might still need to use WebDAV(hint Public Folders) and of course how we write to SharePoint.
I'll start posting some of the code samples over the next week.

There’s lots of other sessions including ones from Steve Smith on SharePoint and Richard Siddaway on PowerShell, should be a good one.

Heres the details of the Event:
The Next EVO Community Day - June 21st: Microsoft Campus Thames Valley Park Reading

Event Agenda
09:30 Start
09:30 - 10:00 Keynote
10:00 - 10:25 Introductions to groups (Including LiveMeeting, Longhorn, Virtualisation)
10:25 - 10:55 Vista
10:55 - 11:10 Break
11:10 - 12:40 Office, SharePoint, Groove
12:40 - 13:25 Lunch
13:25 - 14:55 Break-out sessions
14:55 - 15:10 Break
15:10 - 15:40 OCS + UM
15:40 - 16:40 Exchange and PowerShell
16:40 - 16:55 Break
16:55 - 17:30 Q&A

Further agenda information can be found here:  http://www.ukusergroups.co.uk/Agenda.html

To sign up and more information: http://www.ukusergroups.co.uk/

I’m presenting at the next UK PowerShell User Group meeting on March 22nd doing an updated talk around using PowerShell with SharePoint featuring an intro to PowerShell,  Demos and roundup with SharePoint/PowerShell gotchas and 'tips and tricks'.

The talk should be be of interest of anyone who might like to talk to a managed API with Powershell.

I’m doing the first talk and Richard Siddaway is doing the second session with a talk on using ActiveDirectory with PowerShell.
If you need an intro to using PowerShell or want or ask more advanced questions this will be a good place to be.

Location:
Memphis Room
Microsoft Building 3
Thames Valley Park
Reading

Registration 18:00
Start           18:30

You need to register for attendance so follow the instructions in this link: http://www.culminisconnections.com/sites/get-psuguk/Lists/Events/DispForm.aspx?ID=2

Hope to see you there.

Following on from the work in my previous post where I set the users Picture property in their profile the next step is to add a Contact Web Part to our imported publishing pages. I’m using the default layout page to add the contact Web Part to, this page has the Web Part Zones underneath the content fields but you could use another layout that has a Web Part zones to the right of the content fields and of course you can use SharePoint Designer to create your own layout formats and embed the Contact control without using code.

This is how our publishing pages will look once we have added the Web Part to each page

An interesting feature of a Publishing page is that it has a contact property where you can assign user details to each page, you can either lookup the user from the picker in which case the page will pull the users details from the profile database or you can type in the details yourself.

The nice thing about the Contact Web Part is that once you have added it to a publishing page it will automatically pull the picture and the users description (if set in the Web Part) that has been assigned to the page from the profile database.

One bad thing about the part is you only get the choice to put the users name left or right not top or bottom.

So on to the code, I need a function that will take a site URL and then set the default Publishing Page’s contact property and then add the Web Part to the page.

# Function:           Add-ContactWebPart
# Description:        Adds the Contact User Web Part to a publishing page
# Parameters:         SiteURL     -     Server relative URL of the Area 
#                     UserName -     UserName to show as the contact in domain\user format
#
# Requirements:       Needs to have the System.Web assembly loaded
# 
function Add-ContactWebPart($SiteURL, $UserName)
{
$comment = "Contact WebPart Added"

$site = new-object Microsoft.sharePoint.SPSite($SiteURL)

$web=$site.OpenWeb()

$user= $web.Users.get_item($UserName)

$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)

$defaultpage=$pubweb.GetPublishingPages()[$pubweb.DefaultPage]            

$defaultpage.CheckOut()

# Set Contact 
"Setting Contact on " + $pubweb.url + " to " + $user.Name
$defaultpage.set_Contact($user)
$defaultpage.Update()

$webpartmanager=$web.GetLimitedWebPartManager($defaultpage.Url,  [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

$webpart=new-object  Microsoft.SharePoint.Portal.WebControls.ContactFieldControl
$webpart.ChromeType=[System.Web.UI.WebControls.WebParts.PartChromeType]::TitleOnly;
$webpart.Title="Page Contact"
$webpart.PicturePosition=[Microsoft.SharePoint.Portal.WebControls.PictureDirection]::Left
$webpart.IsDisplayJobTitle=$true
$webpart.IsDisplayPicture=$true


$webpartmanager.AddWebPart($webpart, "LeftColumnZone", 0);


" Checking in page"
$defaultpage.CheckIn($comment)

# Publish
if($defaultpage.listItem.ParentList.EnableMinorVersions -eq $true -and $publishingPage.ListItem.File.MinorVersion -ne 0)
{
        " Publishing"
        $defaultpage.listItem.File.Publish($comment)
}


# If moderation is being used handle the approval    
if ($defaultpage.listItem.ParentList.EnableModeration)
    {

        $modInformation = $defaultpage.listItem.ModerationInformation
        
        " Moderation on, Current Status: " + $modInformation.Status

        # Check for pending approval
        if($modInformation.Status -ne [Microsoft.SharePoint.SPModerationStatusType]::Approved)
        {
            " Approving"
            $defaultpage.ListItem.File.Approve($comment)
        }
            
    }
    

# Clean up
$pubweb.Close()
$web.Close()
$site.Close()

}

In this code we find the SPUser object for the given username and set the Contact property of the PublishingPage to it. We then add the web Part using the new SPLimitedWebPartManager class. Most of the code is concerned with checking the page out and back in and assumes the page is not already checked out.

An interesting line is

$defaultpage=$pubweb.GetPublishingPages()[$pubweb.DefaultPage]

I'm indexing into the collection return by GetPublishingPages because Powershell doesn't support generics in the current version.

Now we have the portal setup I want to add a Contact WebPart to each page but before I can do that I have to add a picture for each user I have imported, in order to keep this post a little shorter I’m only going to concentrate on using the UserProfile API’s to set our picture for each user.
(The Contact WebPart is MOSS WebPart that shows a users name and description and optionally their picture)
The field that we are going to set programmatically is accessed on the Users edit profile page as Picture:

Once set this will display the picture on the user profile like this

To do this I need to revisit our User.csv import file and add an extra field that gives the name of the JPG file that holds the users picture.
I’m going to assume that the previous blog post Upload a directory of files in 4 lines has already uploaded the users picture to the SiteCollectionImages picture library, in real life you’d probably use a separate picture library.

Ideally a profile import has occurred after we have added the users to Active Directory and populated the SharePoint profile database.

Now to set the Users Picture property we know to know the Property Name of the Picture Field.
To make this easy to find out here’s the first function for our toolbox Get-SPUserProfileConfigManager.
This function returns a UserProfileConfigManager (http://msdn2.microsoft.com/en-us/library/microsoft.office.server.userprofiles.userprofileconfigmanager.aspx), note this is the new class that resides in the Microsoft.Office.Server namespace not the v2 obsolete one that lives in Microsoft.sharePoint.Portal.UserProfiles.
Also ignore the sample currently given in the MSDN documentation above, it won’t work as it uses the old classes where you pass a PortalContext to the constructor whereas the new version of the classes take a ServerContext object.

# Function:          Get-UserProfileConfigManager
# Description:       return a UserProfileConfigManager object which is used for management of MOSS User Profiles
# Parameters:        PortalURL          URL for the Portal Site Collection    
#
#
function Get-UserProfileConfigManager([string]$PortalURL)
{

# Need to get a PortalContext object 
# as we do not have a HttpContext we need to source one the hard way

$site=new-object Microsoft.SharePoint.SPSite($PortalURL)
$servercontext=[Microsoft.Office.Server.ServerContext]::GetContext($site)
$site.Dispose() # clean up

# Return the UserProfileConfigManager
new-object Microsoft.Office.Server.UserProfiles.UserProfileConfigmanager($servercontext)


}

Once we get the UserProfileConfigManager we can call GetProperties and list the internal and display names for each profile property

$cm=get-userprofileconfigmanager "http://sps:2828" 
$cm.getproperties() | select name, displayname

Name                                    DisplayName                            
----                                    -----------                            
UserProfile_GUID                        Id                                     
SID                                     SID                                    
ADGuid                                  Active Directory Id                    
AccountName                             Account name                           
FirstName                               First name                             
LastName                                Last name                              
PreferredName                           Name                                   
WorkPhone                               Work phone                             
Office                                  Office                                 
Department                              Department                             
Title                                   Title                                  
Manager                                 Manager                                
AboutMe                                 About me                               
PersonalSpace                           Personal site                          
PictureURL                              Picture                                
UserName                                User name                              
QuickLinks                              Quick links                            
WebSite                                 Web site                               
PublicSiteRedirect                      Public site redirect                   
SPS-Dotted-line                         Dotted-line Manager                    
SPS-Peers                               Peers                                  
SPS-Responsibility                      Responsibilities                       
SPS-Skills                              Skills                                 
SPS-PastProjects                        Past projects                          
SPS-Interests                           Interests                              
SPS-School                              Schools                                
SPS-SipAddress                          SIP Address                            
SPS-Birthday                            Birthday                               
SPS-MySiteUpgrade                       My Site Upgrade                        
SPS-DontSuggestList                     Don't Suggest List                     
SPS-ProxyAddresses                      Proxy addresses                        
SPS-HireDate                            Hire date                              
SPS-LastColleagueAdded                  Last Colleague Added                   
SPS-OWAUrl                              Outlook Web Access URL                 
SPS-ResourceSID                         Resource Forest SID                    
SPS-ResourceAccountName                 Resource Forest Account Name           
SPS-MasterAccountName                   Master Account Name                    
Assistant                               Assistant                              
WorkEmail                               Work e-mail                            
CellPhone                               Mobile phone                           
Fax                                     Fax                                    
HomePhone                               Home phone                             

So from this list I see that I need to set the PictureURL property, to get a UserProfile we first need a UserProfileManager object:

# Function:           Get-SPProfileManager
# Description:        Return a UserProfileManager object which is used for accessing MOSS User Profiles
# Parameters:         PortalURL          URL for the Portal Site Collection    
#
function Get-SPProfileManager([string]$PortalURL)
{

# Need to get a PortalContext object 
# as we do not have a HttpContext we need to source one the hard way

$site=new-object Microsoft.SharePoint.SPSite($PortalURL)
$servercontext=[Microsoft.Office.Server.ServerContext]::GetContext($site)

$site.Dispose() # clean up

# Return the UserProfileManager
new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($servercontext)


}

And then a helper function Get-SPUserProfile to obtain the UserProfile object itself:

# Function:           Get-SPUserProfile
# Description:        Return a UserProfile object, this will be created if it does not exist
# Parameters:         PortalURL          URL for the Portal Site Collection    
#                     DomainUser        UserName in Domain\user format
function Get-SPUserProfile([string]$PortalURL, [string] $DomainUser)
{

$upm= Get-SPProfileManager([string]$PortalURL)

if ($upm.UserExists($DomainUser) -eq $false)
{
    $upm.CreateUserProfile($DomainUser)

}

$upm.GetUserProfile($DomainUser)


}

Note that this function will create the UserProfile if it does not already exist.

Now we just need a function that makes it easy to set a single UserProfile property, if you have multiple properties to set it would be best to do them all at once and then call commit.

# Function:           Set-UserProfileProperty
# Description:        Sets a property on a User Profile
# Parameters:         UserName          [optional] UserName in Domain\user format    
#                     PropertyName        Property to set
#                     PropertyValue        Property Value to set
#                     $UserProfile        UserProfile object, if using this in a loop this should be set 
#
function Set-UserProfileProperty([string]$UserName, [string] $PropertyName, [string] $PropertyValue, [Microsoft.Office.Server.UserProfiles.UserProfile] $UserProfile)
{
    # If we are not passed a UserProfile object then create it
    #
    if ($UserProfile -eq $null)
    {
        $UserProfile = Get-SPUserProfile($UserName)

    }

    $UserProfile[$PropertyName].Value= $PropertyValue
    $UserProfile.Commit()

}

Note this function can either be called with a pre-created userProfile object or a UserName.

Heres the updated Users.CSV with the Picture Field added at the end  

LoginName, DisplayName, FirstName, LastName, Email, Picture
brianb, Brian Ballack, Brian, Ballack, brianb@contoso.com, cowner10.jpg
walterf, Walter French, Walter, French, walterf@contoso.com, cowner12.jpg

Now a function to tie this all together, it imports the CSV files, locates the user profile by login name and updates the user’s Picture URL:

function Set-UserPictures([string] $PortalURL, [string] $UserFile, [string] $Domain )
{

    Import-Csv $UserFile | foreach-object { 
                    $name=$Domain + "\" + $_.LoginName; 
                    $fullURL=$PortalURL + "/" + $_.Picture; 
                    Set-UserProfileProperty $PortalURL  $name  "PictureURL" $fullURL } 
}

 And you can make use of all of the above code by running this command:

Set-UserPictures "http://sps:2828" "users.csv" "contoso"

Ok now we're all set to add the Contact WebPart to each publishing page in the next post.

Made the UK PowerShell User Group meeting last night in Wokingham, just, the weather and people having accidents on the M3 and M4 kept me late. Got to try out my new Acer GPS unit based on Windows Mobile 5, worked beautifully until setting the return journey when a fatal exception dialog popped up on route calculation, I had to reboot the unit, having seen that dialog many times developing on WM I just had to laugh.

Nice to meet other PowerShell enthusiasts, kudos to PowerGadgets for supplying the beer and pizza and Global Knowledge for hosting.

The meeting was hosted by all round good guy Thomas Lee along with Richard Siddaway. Thomas gave an interesting presentation on PowerShell installation a lot of which I didn't know.

One point to come out of the discussion was the number of profiles that PowerShell will load when it first starts up. Here are the locations and order the profiles get loaded in, note these files won't exist unless you or your admin has created them

1. %windir%\system32\WindowsPowerShell\v1.0\profile.ps1  (all users, all shells)
2. %windir%\system32\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps1 ( all users, the Windows Powershell shell)
3. %userprofile%\My Documents\WindowsPowerShell\profile.ps1  (per user, all PowerShell versions)
4. %userprofile%\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 ( per user and the default Windows Powershell shell)

Now you can put code or functions in each of these files but the last loaded file wins if there are any conflicts.

This could be a problem with some companies that would like to define a corporate wide profile for every user and put it in system32\WindowsPowerShell\v1.0, as a user I can override any of the company function definitions with my own code in my own profile. You could lock down the PowerShell %userprofile% files but that might cause other problems.

Someone pointed out at the meeting what was needed is a readonly profile that can be loaded globally and last for every user but hey presto there's a PowerShell team blog out today on making functions read-only http://blogs.msdn.com/powershell/archive/2007/01/25/controlling-powershell-function-re-definition.aspx , now that's what I call service.

As the meeting closed Thomas also gave out a USB Pen drive to everyone who turned up loaded with PowerShell related goodies, woo hoo free stuff, and oh yeah I'll be speaking at the next meeting about controlling SharePoint with PowerShell, should happen sometime in March.

As a follow on from my previous post we can do some neat calculations on the amount of data stored in MOSS personal sites using Powershell.

Using the measure-object CmdLet against the StorageUsedMB property we can calculate the number of personal sites (+1 one as it includes the root site), average size of of each site, smallest, largest and total storage size of all sites.

Again assuming http://sps:20488 is where your personal sites are hosted

PoSH C:\demo> $output=stsadm -o enumsites -url "http://sps:20488"
PoSH C:\demo> $xml=[XML]$output
PoSH C:\demo> $xml.sites.site | measure-object storageusedmb -min -max -sum -average | format-table

Count Average Sum Maximum Minimum Property
----- ------- --- ------- ------- --------
5      0.62   3.1 0.7     0.4     StorageUs...

To get a list of the sites in question with the largest at the top use -descending on the sort CmdLet:

PoSH C:\demo> $xml.sites.site | sort storageusedmb -descending | select url, owner, storageusedMB | format-table

Url                         Owner                    StorageUsedMB
---                         -----                    -------------
http://sps:20488/person... CONTOSO\mike               0.7
http://sps:20488/person... CONTOSO\jeff               0.7
http://sps:20488/person... CONTOSO\administrator      0.7
http://sps:20488           CONTOSO\administrator      0.6
http://sps:20488/person... CONTOSO\brianb             0.4

And if you just want the top 2 offenders us the -first option on the select-object CmdLet

PoSH C:\demo> $xml.sites.site | sort storageusedmb -descending | select url, owner, storageusedMB -first 2 | format-table

Url Owner StorageUsedMB
--- ----- -------------
http://sps:20488/person... CONTOSO\mike 0.7
http://sps:20488/person... CONTOSO\jeff 0.7

Obviously in real life those figures would be a lot larger!

A point came up at the UK SharePoint User Group Chrismas drink, about Personal sites and whether they were top level sites i.e they exist as records in the Sites table and are the top level container for all its subwebs, I hadn’t checked this in v3 so a quick check with PowerShell and stsadm confirms that this is still the case as in V2

Assuming http://sps:20488 is where your personal sites are hosted calling stsadm -o enumsites and processing the returned XML in PowerShell gives us

PoSH C:\demo> $output=stsadm -o enumsites -url "http://sps:20488"
PoSH C:\demo> $xml=[XML]$output
PoSH C:\demo> $xml.sites.site

Url : http://sps:20488
Owner : CONTOSO\administrator
ContentDatabase : WSS_Content_11fba01f-f0c4-4a05-a3c3-868499fd31ce
StorageUsedMB : 0.6
StorageWarningMB : 0
StorageMaxMB : 0

Url : http://sps:20488/personal/administrator
Owner : CONTOSO\administrator
ContentDatabase : WSS_Content_11fba01f-f0c4-4a05-a3c3-868499fd31ce
StorageUsedMB : 0.7
StorageWarningMB : 80
StorageMaxMB : 100
Etc…

Now that I have added some content to our portal I want to approve and publish all pages in each publishing web.

To do this I've created a function that takes an MOSS PublishingPage object and a comment that will be added when we check-in, approve and publish.

# Function: Approve-PublishingPage
# Description: Approve a single page in a Publishing Web
# Parameters: publishingPage PublishingPage object
# comment Comment to accompany the check-in/approve/publish
#
function Approve-PublishingPage ([Microsoft.SharePoint.Publishing.PublishingPage]$publishingPage, [string]$comment)
{
" Publishing Page: " + $publishingPage.Name

$listitemfile = $publishingPage.ListItem.File

# Check item if checked out
if ($listitemfile.Level -eq [Microsoft.SharePoint.SPFileLevel]::Checkout)
{
   " Checking in page"
   $listitemfile.CheckIn($comment,[Microsoft.SharePoint.SPCheckInType]::MajorCheckin )
}


# If moderation is being used then handle the approval and publishing
if ($publishingPage.ListItem.ParentList.EnableModeration)
{
   $modInformation = $publishingPage.ListItem.ModerationInformation

   " Moderation Enabled"

   # Check for pending approval
   if($modInformation.Status -eq [Microsoft.SharePoint.SPModerationStatusType]::Pending)
   {
      " Approving"

      $listitemfile.Approve($comment)
   }

   # Publish
   if($modInformation.Status -eq [Microsoft.SharePoint.SPModerationStatusType]::Draft)
   {
   " Publishing"
   $listitemfile.Publish($comment)
   }
}
}

this function will be called from Approve-AllPagesInSPWeb

# Function: Approve-AllPagesInSPWeb
# Description: Loop through all the pages in a Publishing Web and checkin and approve them
# Parameters: web SPWeb object
# comment Comment to accompany the checkin/approve/publish
#
function Approve-AllPagesInSPWeb([Microsoft.SharePoint.SPWeb]$web, [string]$comment)
{

# Check this is a publishing web
if ([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web) -eq $true)
{

$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web);

"Checking $($pubweb.URL)" 

   $pubcollection=$pubweb.GetPublishingPages() 

   for($i=0; $i -lt $pubcollection.count; $i++)
   {
      Approve-PublishingPage $pubcollection[$i] $comment
   }

}

}

Now I'd like to use a foreach look around the GetPublishingPages collection but that's not possible due to lack of Generic support in PowerShell at the moment, so an index loop does the job.

To approve all pages in all webs we can pipe the SPWebs to a foreach loop and pass the SPWeb object to Approve-AllPagesInSPweb

$site = spsite "http://yourmossserver"
$site.allwebs | foreach-object {Approve-AllPagesInSPweb $_ "System Approval"}

Added as a function approveall it produces this output

In the next step I'll add a Contact WebPart to every page.

In a previous post I've added content to the publishing pages in the legal and finance divisions and its useful to know what fields are in a list when working with the SharePoint API or say the Query By Content WebPart . Yes you can do using the UI but its a pain.

First get the SPWeb object for our site

$site=spweb "http://sps:2828/divisions/finance"
$web=$site.Openweb()

now show the lists on the site

$web.lists | select title,contenttypes

Title                                   ContentTypes                          
-----                                   ------------                          
Documents                               {Document, Folder}                    
Images                                  {Document, Folder}                    
Master Page Gallery                     {Master Page, Folder}                 
Pages                                   {Page, Article Page, Welcome Page, F...
Workflow History                        {Workflow History}                    
Workflow Tasks                          {Task, Folder}                        

The Pages list holds the publising pages so let's list its fields

$web.lists["Pages"].Fields | select title, internalname, typedisplayname | sort title

Title                      InternalName               TypeDisplayName         
-----                      ------------               ---------------         
Approval                   Approval                   Workflow Status         
Approval Status            _ModerationStatus          Moderation Status       
Approver Comments          _ModerationComments        Multiple lines of text  
Article Date               ArticleStartDate           Date and Time           
Byline                     ArticleByLine              Single line of text     
Check In Comment           _CheckinComment            Lookup                  
Checked Out To             CheckedOutTitle            Lookup                  
Checked Out To             CheckoutUser               Person or Group         
Checked Out To             LinkCheckedOutTitle        Computed                
Client Limit               Client_x0020_Limit         Number                  
Collect Feedback           CollectF                   Workflow Status         
Collect Signatures         CollectS                   Workflow Status         
Contact                    PublishingContact          Person or Group         
Contact E-Mail Address     PublishingContactEmail     Single line of text     
Contact Name               PublishingContactName      Single line of text     
Contact Picture            PublishingContactPicture   Hyperlink or Picture    
Content Type               ContentType                Choice                  
Content Type ID            ContentTypeId              Content Type Id       

etc...

There are a lot of fields, to get the count use $web.lists["Pages"].Fields | measure-object
That gives 92 fields for the Pages library.

To see the content publishing pages themselves use

$web.lists["Pages"].Items | select name, file, level

Name                       File                                           Level
----                       ----                                           -----
default.aspx               Pages/default.aspx                             Draft
Client1.aspx               Pages/Client1.aspx                             Published

and finally two functions for our toolbox to make calling these easier

function get-SPListFields([string]$URL, [string]$ListName)
{
$site=get-spweb $URL
$web=$site.OpenWeb()
$list=$web.Lists[$ListName]
$list.Fields
}

function get-SPListItems([string]$URL, [string]$ListName)
{
$site=get-spweb $URL
$web=$site.OpenWeb()
$list=$web.Lists[$ListName]
$list.Items
}

These functions will come in useful later when we approve pages in a site with PowerShell.

One of the things that the PowerShell team has always pointed out is the importance of naming conventions in functions.
Most of the bult-in PowerShell functions have a verb-noun format i.e. get-process, get-service etc..
Keeping things consistent across the different types of providers helps with the learning process as you can almost guess what a cmdlet would be called once you know the noun.

Up to now I thought this was just a syntax sugar but this blog entry from the main PowerShell guy Jeffrey Snover points out an important benefit if you name your functions correctly.
When you type a function name, and PowerShell tries to match the correct code to call, it will automagically add a get- to the function name and try to match on that if it fails to find a function of the exact name.

Heres an example take the simple get-SPSite function

function get-SPSite([string]$url)
{
   new-object Microsoft.SharePoint.SPSite($url)
}

I've been using this as $a=get-spsite "http://server" but I could have used $a=spsite "http://server". Its a small thing but if you're typing on the command those extra four characters add up plus it almost looks like C# code not having to use a lengthy namespace prefix.

Likewise for get-SPWeb

function get-SPWeb([string]$url)
{
   $site=new-object Microsoft.SharePoint.SPSite($url)

   $site.OpenWeb()
}

Everyone and their dog will have this link but I'll post it anyway.

Windows PowerShell 1.0 has been released. This page has a list of the download links for XP, Windows Server 2003 and Vista .

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

You might have to be patient as the links were a bit flakey when I tried them.

A point to note is that the Vista version is at RC2 status. Jeffrey Snover explains the Vista release delay here http://blogs.msdn.com/powershell/archive/2006/11/15/windows-powershell-windows-vista.aspx. Checking the comments it seems some people are getting hot under the collar about the delay but as I see it the PowerShell team have done a great job and by all accounts the only difference between RC2 and RTM is the installer. Personally given my bad beta experiences of Vista I'm happier installing the RC2 of PowerShell than the RTM of Vista.

Also worth a download is the Documentation Pack as it contains a Getting Started Guide and a User Guide.

Ok now we have the main structure of our Portal with the new Areas we wanted and we need to start adding some content.

As the Area's we have created are Publishing sites we're going to start using the new Publishing API's in WSS to add content.

The first function to help us with this is called Add-Content. This function takes a Site Collection URL, Area URL, Contents Title, Content Text in HTML format and a check-in comment. This function adds the given text and title to the default content page in the Publishing site.
With a few changes you could modify it to add to a specific content page.

# Function: Add-Content
# Description: Add the given text and title to the default publishing page in the publishing web
# Parameters: SiteCollectionURL URL for the root of the Site Collection
# Area Relative URL to the site/subweb/area
# Title Title string for the page
# Text Content to publish
# Comment Checkin comment
function Add-Content($SiteCollectionURL, $Area, $Title, $Text, $Comment)
{

$url = $SiteCollectionURL + "/" + $Area

write-host "Adding content to " $url

$site = new-object Microsoft.SharePoint.SPSite($url)

$web = $site.OpenWeb()

$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)

$pp=$pubweb.DefaultPage

$pp.CheckOut()

# Set the properties
$item=$pp.Item
$item.set_Item("Title",$Title)
$item.set_Item("PublishingPageContent",$Text)
$item.Update()

# Checkin, Approve and Publish
$pp.CheckIn( $Comment )
$pp.Approve( $Comment )
$pp.Publish( $Comment )


}

Note the set_Item syntax, the SharePoint item property seems to conflict with PowerShell's built in properties.
This code assumes Moderation is turned on the Publishing Site.

So we have a handy function to add content but again I want to source that content from an external source.
In this case it's an XML file called content.xml the start of which looks like this:
<contents>
<content>
<area>Divisions/Finance</area>
<title>
Finance Division
</title>
<text>&lt;b&gt;Lorem ipsum dolor sit amet, consectetuer adipiscing elit.&lt;/b&gt;&lt;hr/&gt;&lt;br/&gt; Nullam hendrerit lacinia purus. Proin vulputate porta nisl. Aliquam commodo lobortis lacus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Sed quis leo imperdiet nisl ultrices fringilla. Praesent enim est, commodo sed, pharetra mattis, condimentum ut, arcu. Morbi aliquet lacus vel elit. In quis nibh. Vestibulum tincidunt. Sed quis sem.
Maecenas lobortis convallis dolor. Nunc rutrum, nunc ac elementum tempor, velit est vehicula libero, eu fermentum lacus lacus ac diam. Curabitur risus quam, dignissim ut, mollis vel, nonummy at, metus. Mauris elit libero, interdum sit amet, sollicitudin nec, eleifend vel, magna. Aliquam at ipsum. Ut rutrum convallis turpis. Quisque urna quam, tincidunt id, pretium a, dignissim ac, neque. Donec ipsum. Sed ornare pretium diam. Phasellus massa. Morbi porttitor purus eget turpis. Sed vel lectus. Etiam egestas nibh vitae augue. Ut felis arcu, fermentum sed, venenatis eget, tincidunt et, lorem. Etiam commodo nisi ut nisl. Morbi augue enim, accumsan eu, dignissim a, scelerisque non, nunc.
Praesent mauris ante, pretium eget, volutpat quis, congue eget, odio.&lt;br/&gt; Praesent sed orci nec sapien molestie viverra. Aenean pulvinar dictum mauris. Quisque ligula est, vestibulum id, consequat vel, ullamcorper id, libero. In tristique. Duis turpis augue, egestas sed, semper eget, dignissim sed, nisl. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Curabitur feugiat dolor cursus lacus. Curabitur dui augue, tempus id, sollicitudin vel, pharetra a, augue. Donec vestibulum dictum ligula. Ut velit dui, dignissim at, interdum quis, convallis a, arcu. Vivamus neque lorem, sollicitudin et, malesuada sed, rhoncus eu, pede. Aliquam hendrerit imperdiet lacus. Duis iaculis fringilla risus. Aliquam pretium ante quis arcu. Nam erat est, porttitor non, venenatis at, auctor sed, libero. Sed condimentum, ante vitae dignissim egestas, dolor nisl rutrum elit, nec ultrices lacus ipsum et pede. Duis dolor turpis, lacinia eu, facilisis ut, fermentum sit amet, nisl. Proin imperdiet mauris a lacus. Nullam suscipit imperdiet tellus.
</text>
........

Its a simple format that has the relative URL of the destination area, the content title and the contents in encoded HTML in its XML nodes. I've encoded the HTML as support for CDATA sections is not as easy as it should be in PowerShell at the moment.

Now I was going to use the import-xml cmdlet that was available in Monad but that seems to have disappeared in recent builds so to import this file I'm going to use the get-content cmdlet, create a variable from it (the $() syntax) and cast it to XML

$xml=[XML]$(get-content Content.xml)

The [XML] is a shorthand way to load the XML into an XMLdocument class
so

$xml | get-member

shows the typename as being the XmlDocument class. If you're used to using this in C# or VB.Net then you have access to the class as normal but the cool thing about PowerShell is the $xml variable now has extra properties that match the nodes in the XML file

$xml.contents.content

will list the content nodes and

$xml.contents.content[0].area

will show Divisions/Finance

The import-content function will do all the hard work.
I'm just piping the list of content nodes into the add-content function and referencing the node name as properties

# Function: import-content
# Description: Use the XMl import file to import some sample content into the Publishing Web
# Parameters: SiteCollectionURL URL for the root of the Site Collection
# ImportFile XML file containing the sample data
function import-content($SiteCollectionUrl,$ImportFile)
{

$xml=[XML]$(get-content $ImportFile)

# Loop through the xml items
$xml.Contents.Content | foreach-object { Add-Content $SiteCollectionUrl $_.Area $_.Title $_.Text }


}

So with a few lines of code this function is loading the conten