PowerShell

Speed up PowerShell Startup

Darrin Bishop — Tue, 15 Jul 2008 21:47:44 GMT

I caught this little gem (Update-Gac.ps1) on the PowerShell Team blog while I was catching up on posts. This script will Ngen the PowerShell assemblies for a quicker start up. Ngen is a .NET utility that will create a native images that are stored in a cache which can be then used by the framework alleviating some of the JIT-ing at startup. I ran this script and noticed a big difference in the start up times. I will run this on all my machines.

GetActiveFeatureDefinitions - A SharePoint PowerShell Function

Darrin Bishop — Mon, 14 Jul 2008 05:49:23 GMT

Here is one more feature-related PowerShell script to quickly display which features are active based on a given SharePoint url. This script takes a SharePoint end point (url) as the first parameter and optional exclude parameters for each of the possible feature scopes. This function will output SPFeatureDefinition objects that will display in the PowerShell host or can be used further in the pipeline as SPFeatureDefinitions.

I want to point out that this function returns SPFeatureDefinition objects as the function name suggests. Why do I return SPFeatureDefintion objects? Simple, the SPFarm object does not contain a collection of activated features while all the other scopes (WebApplication, Site, and Web) do. There is no SPFeature to retrieve from the SPFarm, all intstalled features scoped for the farm are active. Since I use this function as a simple and quick way to see what features are activated based on the url endpoint I really only need the feature definition which contains the interesting properties including displayname, scope and hidden.

Now one warning - this function simply determines which features are activated based on the url end point. This does not mean that the feature directly affect the particular web or site. Some features are scoped at the farm or web app for a particular end point but does not manifest itself in the site or web. For example, you might find publishing features listed as active when you are looking at a team site. Even though the team site is not using publishing features the feature is still activated for the farm or web application. For this reason I included parameters that allow you to exclude features scoped at a particular level.

To use this function you must load the Microsoft.SharePoint assembly into your PowerShell host. To load the SharePoint Assembly in a PowerShell session type and run the following command:

[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

And now the function:

function GetActiveFeatureDefinitions
{
   param ([String] $webUrl,
             [Switch] $ExcludeFarm,
             [Switch] $ExcludeWebApp,
             [Switch] $ExcludeSite,
             [Switch] $ExcludeWeb )

   $site = new-object Microsoft.SharePoint.SPSite $webUrl
   $web = $site.OpenWeb()
   $webAPP = $site.WebApplication
   $Farm = $WebApp.Farm

   if(!$ExcludeWeb.IsPresent)
   { $featureDefs = $web.features | %{$_.Definition}}

   if(!$ExcludeSite.IsPresent)
   { $featureDefs += $site.features | %{$_.Definition}}

   if(!$ExcludeWebApp.IsPresent)
   { $featureDefs += $webApp.features | foreach-object{$_.Definition}}

   if(!$ExcludeFarm.IsPresent)
   { $featureDefs += $farm.FeatureDefinitions | Where-Object{$_.Scope -eq 'Farm'}}

   $web.Dispose
   $site.Dispose
   return $featureDefs
}

Here are some example uses of GetActiveFeatureDefintions:

GetActiveFeatureDefinitions http://localhost
GetActiveFeatureDefinitions http://localhost  -excludeFarm
GetActiveFeatureDefinitions http://localhost -excludeFarm -excludeWebApp

Remember the function exports SPFeatureDefinition objects and can be used in the pipeline. Here are a few examples to try:

$fds= GetActiveFeatureDefinitions http://localhost -excludeFarm
$fds.count

GetActiveFeatureDefinitions http://localhost -excludeFarm   | Sort-Object Scope | Format-Table DisplayName, Scope, Hidden, Id -auto

GetActiveFeatureDefinitions http://localhost | Where-Object{$_.Hidden -eq $true} |Sort-Object Scope | Format-Table DisplayName, Scope, Hidden, Id -auto

GetFeatureAndDependencies - A SharePoint PowerShell Function

Darrin Bishop — Mon, 07 Jul 2008 03:18:29 GMT

As stated in my previous post, GetFeatureDefinition - A SharePoint PowerShell Function, I have been working on deploying a solution that contained multiple features which lead me down the road of feature activation dependencies. My current client's hosting environment has me looking to see just what I can pull off with hidden features and cross-scope dependencies. In searching out any best practices around solution and feature packaging Scott Hillier suggested that I dig into the MOSS publishing features to look at how they relied on Activation Dependencies. I just happened to be reading AC's Professional WCM book, SharePoint 2007 Web Content Management Development, where Andrew just happens to be discussing the publishing features.

So what I really wanted to do was to view some key information about a feature and it's dependencies, for a given feature show me it's dependency to include name, id, scope and hidden property If you have not tried to do this - well it is a time-consuming process when you must wade through the feature directory matching up feature activation ids to features.

In my previous life , lets call it BPS (Before PowerShell), I like many developers would have opened up Visual Studio, started a new console project to created a simple application that would dump the features to the screen. A typical one-shot app. But now APS (After PowerShell) I took a few minutes and created a new SharePoint PowerShell function named GetFeatureAndActivationDependencies which outputs to the screen key properties of the feature and any activation dependencies.

So a little housekeeping before the script. First this script relies on the GetFeatureDefintion function in my last post, GetFeatureDefinition - A SharePoint PowerShell Function. Make sure you add this function to your PowerShell host, either in the host itself or via a profile. Next, both GetFeatureDefintion and GetFeatureDefintionAndDependencies must run in a PowerShell host on a WSS 3 or MOSS 2007 server. Finally as stated in all my PowerShell and SharePoint post you must load the SharePoint assembly in the PowerShell environment before you use these functions. To include the SharePoint assembly in the PowerShell environment simply execute the following command in PowerShell:

[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

PowerShell will respond with information about the newly loaded assembly.

So here is the function. It must be run on a WSS 3 or MOSS server with PowerShell

function GetFeatureAndDependencies
{
Param([String] $FeatureId)

getFeatureDefinition $FeatureId | sort-object{$_.DisplayName} |
foreach-object{
   "Feature Definition`n-----------------------------------------------------------"
    $_ | format-table DisplayName, Id, Scope, Hidden -AutoSize

    $dep = $_.ActivationDependencies | foreach-object{getFeatureDefinition $_.FeatureId} | FT DisplayName, Id, Scope, Hidden -AutoSize
    if($dep -ne $null)
    {
     "Activation Dependencies`n-----------------------------------------------------------"
      $dep
    }
    else
    {"No Dependencies"}
}
}

Once the function has been defined in your PowerShell session try the following commands:

GetFeatureAndDependencies

Ok that is a little messy, it will dump every Feature Definition along with any activation dependencies. This next command is "real-world" example. All I have been provided is a Feature Definition id….And to make it more real, I don’t know which feature maps to this ID.

GetFeatureAndDependencies F6924D36-2FA8-4f0b-B16D-06B7250180FA

To close this post, this is an example of a PowerShell script that provides a formatted output to the screen for a report-like view. This script really was not intended to be used as input into another command. The script does not output a clean set of objects.

GetFeatureDefinition - A SharePoint PowerShell Function

Darrin Bishop — Thu, 03 Jul 2008 03:59:35 GMT

I cant believe I have not posted this simple PowerShell function. I have been doing some packaging of features and solutions lately so many of my feature-related scripts come to the foreground.

The GetFeatureDefintion function will return either a single Feature Defintion (SPFeatureDefinition) if you pass in a Feature Id or all feature definitions ( Array of Feature Definitions) on the farm . This is a great little function to include in your profile. Before you attempt to use this function a little housekeeping is in order. First you need to run this in a PowerShell session on a server that has WSS 3 or MOSS 2007. Next, you will need to load the SharePoint assembly into the PowerShell session.

To load the SharePoint Assembly in a PowerShell session type and run the following command:

[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

PowerShell should respond with information about the assembly.

And here is the script:

function GetFeatureDefinition
{
param($featureID="")
  $localFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local
  if($featureID -ne "")
  {
    return $localFarm.FeatureDefinitions | where-object{$_.Id -eq $featureid}
  }
  else
  {
    return $localFarm.FeatureDefinitions
  }
}

Once the function has been defined in your PowerShell session try the following commands:

GetFeatureDefinition

GetFeatureDefinition F6924D36-2FA8-4f0b-B16D-06B7250180FA

Of course you can always format the output using format commands in PowerShell:

GetFeatureDefinition | Format-Table DisplayName, Id, Scope, Hidden

GetFeatureDefinition F6924D36-2FA8-4f0b-B16D-06B7250180FA | Format-Table DisplayName, Id, Scope, Hidden

And of course you can filter and sort using supplied PowerShell commands and the pipeline:

GetFeatureDefinition | Where-Object{$_.DisplayName -like 'Publish*'} | Sort-Object Scope | FT DisplayName, Id, Scope, Hidden

GetFeatureDefinition | Where-Object{$_.Hidden -eq $True} |Sort-Object DisplayName | FT DisplayName, Id, Scope, Hidden

And don’t forget that with PowerShell you are working with objects:

(GetFeatureDefinition | Where-Object{$_.DisplayName -like 'Publish*'} ).Count

(GetFeatureDefinition | Where-Object{$_.Hidden -eq $True}).Count

Tech Ed 2008 - OFC07-TLC - Building Windows PowerShell Cmdlets for Microsoft SharePoint

Darrin Bishop — Sun, 22 Jun 2008 02:26:37 GMT

For those that attended OFC07-TLC - Thanks!

Here are the files and slide deck for OFC07-TLC Building Windows PowerShell Cmdlets for Microsoft SharePoint. The demo builds a simple Get-Web cmdlet and a Web Feature Provider. Remember this is "conference" code and not production code :) demo purposes only!

As always, I am interested in comments and feedback about the demo, slides, or session.

File: http://www.darrinbishop.com/files/OFC07_TLC.zip

Limiting Your SharePoint Objects with PowerShell

Darrin Bishop — Mon, 17 Mar 2008 14:41:26 GMT

In my post "Five Simple But Powerful PowerShell Functions/Filters for SharePoint" I demonstrated five functions and filters that when stung together allowed you to access many of the key SharePoint objects. This post assumes you read Five Simple But Powerful PowerShell Functions/Filters for SharePoint. The five functions and filters are interesting because we can access key SharePoint objects which we will use later in scripts. The problem with the five functions and filters is they lack specificity. They will bring back every object of a specific type on the a SharePoint farm. In some cases this is what you want but in others it simply produces a lot of noise.

I should throw in a note here that lets the readers know that I chose to "design" these functions and filters to be chain-able and return all the objects of a certain type . I certainly could have created functions and filters that would allow the reader to target a very specific object. By including limiting parameters. I felt that design would have created more functions that would require parameters and might be more confusing to administrators that do not have much scripting experience.

Back to the topic of limiting our output. PowerShell has provided an important cmdlet, Where-Object, that can be used for limiting the output to the pipeline. Strategically placing this cmdlet in our existing pipeline will control which objects continue through the pipeline to the next cmdlet and ultimately the host (i.e. the console). First lets look at the syntax for the Where-Object

Where-Object { <Script Block> }

The Where-Object is standard cmdlet verb-noun syntax that we have seen before. The Script Block is new. The author of the PowerShell script provides a block of script that the Where-Object uses to select which objects makes it thought the pipeline. Lets look at a very simple example again using the Get-Process cmdlet.

Now lets look at the output to the host when we execute Get-Process ( the canonical demo example)

Output of Get-Process

Now compare the output when we execute Get-Process | Where-Object { $_.ProcessName -like "SQL*"}

Output of Get-Process | Where-Object { $_.ProcessName -like "SQL*"}

The second example containing the Where-Object cmdlet only passes objects though the pipeline when the current object (referenced by $_ ) has a ProcessName property that begins with the string 'SQL' as defined in the scriptblock delineated by braces. All other objects passed via the pipeline to the Where-Object cmdlets that does not meet the Where-Object criteria is dropped and not passed on to the next cmdlet in the pipeline. In this example is not passed to the default format cmdlet before being sent to the PowerShell console.

So now lets see how we can use the Where-Object to provide some selectivity for our 5 filters and functions. These scripts assume you have followed the Five Simple But Powerful PowerShell Functions/Filters for SharePoint post. Lets start with this example that will return all webs (SPWeb objects) on the local farm ( remember you must run this on a SharePoint server).

Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | format-table title, url

Results of Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | format-table title, url

Now lets add a Where-Object cmdlet:
Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | Where-Object{$_.url -like "*dev*"} | format-table title, url

Results after piping to Where-Object{$_.url -like "*dev*"}

Notice we can now limit what webs are passed on to the next cmdlet. In the last example we limited the SPWeb objects passed to the end of the pipeline to those that contained the substring 'dev'.

[Hint: Not sure what properties of the SPWeb objects to filter on? The Windows SharePoint Services SDK has them all. Another way is to run the following:

$webs = Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web
$webs[0] | Get-Member

This set of cmdlets retrieves all the webs (SPWeb) objects on the local farm and places them in a variable ($webs). The second line will send the first SPWeb to the Get-Member cmdlet and dump the properties and methods to the screen]

Try running this set of cmdlets:

Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | Where-Object{$_.webtemplate -eq 'Wiki'} | format-table title, url, WebTemplate

You will display the title, url and WebTemplate values for webs that were created from the Wiki template.

Need to get a list of all the team site webs? Try:

Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | Where-Object{$_.webtemplate -eq 'STS'} | format-table title, url, WebTemplate

How about a list of all webs that allow anonymous access? Try:

Get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web | Where-Object{$_.allowAnoymousAccess -eq $true} | format-table title, url, WebTemplate

Now a list of site collections:
Get-localfarm |get-webservice | get-webapplication | get-sitecollection | format-table url, owner

And now only site collections on port 8090
Get-localfarm |get-webservice | get-webapplication |Where-Object {$_.Port -eq 8090} | format-table url, owner

Now expand the last set of cmdlets to include a get-web before you end with Format-Table and you will get all webs for site collections on port 8090.

Get-localfarm |get-webservice | get-webapplication | get-sitecollection | Where-Object {$_.Port -eq 8090} | get-web | format-table title, url

Ok, these are very simple examples of limiting the output from our five filters and functions. Working with the Get-Member cmdlet or the SDK will allow you to effectively filter and cut down on the noise.

Find Me at the Bloomington .Net User Group

Darrin Bishop — Tue, 18 Dec 2007 02:53:16 GMT

Find me in Bloomington, Illinois in January. I will be speaking at the Bloomington .NET User Group on January 8 2008. I will be covering SharePoint and PowerShell ( one of my favorite subjects ). For those of you in the Central Illinois area please stop by.

Get the details at: http://bloomingtondotnet.org/

Five Simple But Powerful PowerShell Functions/Filters for SharePoint

Darrin Bishop — Wed, 28 Nov 2007 17:46:19 GMT

To start out, a function in PowerShell is similar to a function in any other development language. (See my last post "Commands in PowerShell" for a little PowerShell basics on command and functions.) It takes zero or more inputs, runs zero or more statements and possibly returns one or more values. Functions in PowerShell are a way to gather up multiple statements into a functional, reusable piece of code. Below is a shell of a basic function in PowerShell.

Function DoThis($var)
{
<Statements>
}

What exactly is a PowerShell filter? A filter is very similar to a function with the exception of the filter keyword.

Filter DoThat($var)
{
<Statements>
}

Both functions and filters can participate in the PowerShell pipeline but they do so in slightly different ways. (To read about the pipeline.. ) The PowerShell pipeline provides the ability to stream the output of one command as input to the next command via the pipe character |. Functions (simple functions) can access the current object in the pipeline using the $Input value and run till completion. Filters access the current object in the pipeline using the $_ variable and run once per object placed in the pipeline. There is a slight but real difference between how a function and filter work but suffice it to say that in simplistic terms Filters work nicer with the pipeline . ( Ok, that is not completely true. There is a way to create a function that will work like a filter but that is not the focus of this post and using filters saves me a few lines of code.)

So here are my simple functions and filters that I end up using all the time.

function Get-LocalFarm
{
return [Microsoft.SharePoint.Administration.SPFarm]::Local
}

filter Get-WebService
{
$webServices = new-object Microsoft.SharePoint.Administration.SPWebServiceCollection($_)
$webServices
}

filter Get-WebApplication
{
$_.WebApplications
}

filter Get-SiteCollection
{
$_.Sites
}

filter Get-Web
{
$_.AllWebs
}

Did I not say they were simple? So what is the big deal about these function and filters? Figure 1 below displays a simple view of a SharePoint Farm object hierarchy. The above five functions and filters allow us to access all of the objects show in Figure 1.

Figure 1: Basic SharePoint Object Model Hierarchy

If you compare the function/filters from above to the hierarchy in Figure 1 you will notice that there is a corresponding filter or function for each object level.

It is very simple - Get-LocalFarm will return the SPFarm object. If you pipe the SPFarm object to Get-SPWebService you will have access to all the SPWebServices associated with the local farm. Chain all five function/filters together and the end result is ALL SPWeb objects on the farm. Since these are small reusable pieces of code you can stop the chain where it makes sense.

Before I demonstrate how you can use these filters and functions let me explain how to set these up in PowerShell.

First you must be on a WSS 3.0 or MOSS 2007 server. Since the SharePoint object model does not remote you must run these from a PowerShell instance on the server.

Next before you add the filters and functions to the PowerShell environment you must add the Microsoft.Sharepoint assembly to the PowerShell environment. To add the Microsoft.SharePoint assembly to the PowerShell environment simply run the following command in PowerShell :

[Reflection.Assembly]::Load(“Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“)

Next copy the function and filters listed above and paste into the PowerShell command window. Since I used these all the time I have these listed in my profile.ps1 file so they load up automatically when I start PowerShell. Now you can use one or more of the function/filters to access any of the object model items shown in Figure 1.

Here are a few examples to play with:

get-localfarm
get-localfarm |get-webservice
get-localfarm |get-webservice | get-webapplication
get-localfarm |get-webservice | get-webapplication | get-sitecollection
get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web

The first example will output a text representation of the SPFarm object for the local farm.
The second example will output zero or more text representations of SPWebService objects associated with the farm. You should be able to guess the objects passed out the pipeline based on the name of the filter.

If you actually executed the last statement in the list of statements above you should have ended up with output similar to Figure 2.

Figure 2 : Screen shot of get-localfarm |get-webservice | get-webapplication | get-sitecollection | get-web

In Figure 2 we see that the SPWeb objects hit the end of the pipeline and was formatted for the host providing us a view into the SPWeb object. A view such as this is not real easy to review particularly when the out scrolls off the screen. So let's format the output so we can get a better view of the results. For an SPWeb object I like to view the URL. We can pipe the SPWeb objects to the format-table cmdlet. The new command looks like:

and the new output looks like:

Figure 3: SPWeb objects piped to Format-Table cmdlet

Figure 3 displays the output of the last set of commands. It shows all web objects on the farm. Although we now only see the url of each SPWeb object sent to the format-table cmdlet we have access to properties and methods of the SPWeb object. So now we have access to each SPWeb object in the farm as it passes though the pipeline. Since we have access to the actual SPWeb object we have access to all the properties and methods of that object and can script against it. That's pretty powerful.

Right now I am sure it appears that there is a lot of noise in the output but the next post we will continue to use these filters and functions along with other PowerShell cmdlets to be more selective in the output.

One last example for you to try
(get-localfarm).solutions | format-table -property name

Yes this will output the name of all solutions installed on the farm

Commands in PowerShell

Darrin Bishop — Tue, 27 Nov 2007 14:58:22 GMT

Commands do the work in PowerShell. Its that simple yet when I speak about PowerShell and SharePoint there always seems to be some confusion on what a command is. That's understandable because in PowerShell there are many ways to execute a command. Yesterday I was speaking with someone and started talking about functions and filters in PowerShell. The person whom I was speaking with had not worked with functions or filters but understood cmdlets and providers.

It seems that if I want to create posts on PowerShell and SharePoint I need to preface it with a post on commands. This way as you read my PS/SP posts you can better understand the commands I use. Don't consider this "the" blog post on PowerShell commands but a simple primer to help clear the ambiguities.

First commands causes actions to happen in PowerShell. Commands allow us to accomplish tasks from listing the files on a file system to opening a text file in notepad. The concept of a command in a "command line" application is not new and probably not confusing. What might be considered confusing is that PowerShell has four basic types of commands. To make things a little more interesting commands of one type can interact with commands of other types.

The four basic command types in PowerShell are:
1) Cmdlets
2) Functions
3) Native
4) Scripts

Cmdlets
The standard demo command for PowerShell appears to be get-process. Get-process cmdlet will ultimately dump process information to the host ( screen). Get-Process is a cmdlet (pronounced command-let). Cmdlets support a normalized naming scheme with the verb-noun syntax. Cmdlets are compiled code that are available to the PowerShell environment. PowerShell has "built-in" cmdlets such as get-process, get-help and where-object to name a very few. Developers can create new cmdlets and register them with the PowerShell host.

To run a simple cmdlet in PowerShell

1. Open PowerShell
2. Type Get-Process at the PowerShell Prompt.
3. Click Enter to execute the cmdlet.

Figure 1: Executing a Cmdlet in PowerShell Host

Functions
Functions organize commands and statements into a reusable chunk of code. Here is an example of a function in PowerShell:

Function WriteDBGFooter
{
"Darrin Bishop Group, Inc."
"www.darrinbishop.com\blog"
}

Functions are compiled when they are defined in the host and are generally available until you restart the host. Functions can take parameters.

To create and execute the WriteDBGFooter function defined above

1. Type the function into the PowerShell Host
PowerShell allows you to add returns while typing. It is "smart enough" to know when the commands are complete. When it is expecting more characters it will display a >> prompt. So you are free to type in a multiline function without PowerShell attempting to execute a partial function. You will need to type one more return at the end of the function to let PS know you are done entering the functions.
2. Type WriteDBGFooter
3. Press Enter to execute

The result should be similar to Figure 2 below. You should be able to use WriteDBGFooter for the life of the PowerShell session without rekeying the function.

Figure 2: PowerShell Function Defined and Executed

Native
Native commands are simple. Native commands are those that run outside the PowerShell process. When you open a .docx file in Microsoft Word you are using a native command.

To execute a Native command:

1. In PowerShell host enter the path to a Word document
2. Enter to Execute

Figure 3 and 4 below displays the PowerShell host and the resulting Word document.

Figure 3: Executing a Native Command

Figure 4:Document Opened in Word

Scripts
Script commands are simply commands that have been saved to the file system. Scripts are commonly saved with a .ps1 extension. Scripts let us save a commonly used set of commands to a file so that we can run it many times without rekeying the script. Scripts are called from PowerShell by file name. If your PowerShell's current location is the same as the location of the script you can execute the script by placing a ./ in front o the script name. The ./ is required when your current PowerShell location is the same as the script location.

One other interesting thing to know about scripts is that scripts will not run by default. PowerShell allows you to set a script execution policy. By default scripts must be signed before they can run. By calling the set-executionpolicy passing in unrestricted value you can bypass this security block. Ofcourse you should really think about what you are doing when you decide to do this. The PowerShell team placed this in the host for a reason.

To set the Execution Policy

1. Type set-executionpolicy -ExecutionPolicy Unrestricted
2. Click Enter to execute.

(Note, if you are running Vista you might need to run PowerShell as an administrator to make this policy change)

To demonstrate a script I will explain how to create a script that looks at the Application event log and counts the number of Outlook events .

1. Open Notepad
2. Type into Notepad the following commands

$logItemCount = (get-eventlog -logName Application | Where-Object {$_.Source -eq "Outlook"} ).count
"You have $logItemCount Outlook items in the Application event log."

3. Save the file as GetOutlookLogItems.ps1 . For this example I have saved GetOutlookLogItems.ps1 to c:\PSScripts.
4. Type c:\PSScripts\GetOutlookLogItems.ps1
5. Click Enter to execute

Figure 5 displays the script in Notepad and Figure 6 displays the PowerShell console after executing the script.

Figure 5: Creating a Script

Figure 6: Executing a Script

That’s a very basic overview of the command types in PowerShell. I really boils down to executing commands in the PowerShell host regardless of the command type. Cmdlets are great if there is one that works for your situations. I use functions a lot to script against an object model because I do not have to compile or register a function like a custom cmdlet ( I do build and use custom cmdlets when it suits me). Functions are a great way to quickly encapsulate one or more commands for reuse I use scripts to roll up many commands and functions to achieve a particular objective. With scripts I can create, test, fix and then reuse whenever I need the script.

Barcelona, Spain PowerShell/SharePoint Scripts

Darrin Bishop — Sat, 24 Nov 2007 02:18:06 GMT

As promised here are the PowerShell scripts I used in my session at ITForums in Barcelona Spain.

PS_SPDemoCode.zip

If you want to follow along with the demo script (demoScript.txt) you must place the files in the correct location or change the included demo script. Once the files are placed in the correct location on the SharePoint server you can copy and paste the commands from demoScript.txt to PowerShell.

To setup the environment to follow the demoScript.txt:

1) Copy DBGDesignLinks to the SharePoint server's feature folder (12\Template\Feature). This simple feature will add two links to the Site Actions menu to access the Features management page.

2) Copy the code located in the Microsoft.PowerShell_profile.ps1 file to your profile.ps1 file. To locate your profile simply type in $profile at the PowerShell prompt. The Microsoft.PowerShell_profile.ps1 file contains some basic functions such as AddFeatureToWeb, RemoveFeatureToWeb as well as loading the SharePoint assembly and creating PSDrives. You will need to exit and restart PowerShell so PowerShell will load up the functions in the profile.

3) Copy the files located in the PSScripts folder to C:\ PSScripts. These script files are used in the demoScript.txt file to Create and Delete sub webs. There is also txt file that contains the information about the sub webs that will be created.

Once done, you can copy the commands from the demo script to recreate the demo. The basic demo will:

Install a feature
Create sub sites from a configuration file
Add the feature to the sub sites
Find the sub sites with the feature
Remove the feature from the sub site
Delete the sites
Uninstall the feature.

Check back soon for a few more simple but powerfull PowerShell functions and filters that can be easily chained togehter to provide basic access to key SharePoint objects.