Lately this contribution from Barto Molina caught my attention in the TechNet Forums: http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/dd50264d-6f4d-4b31-bf7f-959efdbc6b7c/. His C# code iterates through the solutions stored in the local farm and saves them to the file system under the form of a standard WSP file.

You’ll find a “PowerShellized” version of it over here: http://www.marc-antho-etc.net/scriptdetail.aspx?script=spExtractSolutions.ps1.txt. I hope you’ll find it useful.

And cut!

I often have to perform maintenance or configuration activities on all servers members of a SharePoint farm suchs as archiving or parsing logs, recycling IIS application pools… While you could simply store all servers’ name in a plain text file, I always prefer a more dynamic way and as usual now, PowerShell will do the job.

Begin with loading the assembly…

[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

Then connect to the farm:

$spFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local

And finally populate an array with all servers:

$spServers = $spFarm.Servers|Select Farm,DisplayName,Address,Role

Now the problem with this array is that it also contains servers that are not real servers but rather “network names” such as the SMTP host for mail-out or the SQL database server name and instance. If you want to retrieve only server where SharePoint is installed and running, use this filter

$arrServers = $spFarm.Servers|Where {!($_.Role -eq 'Invalid' -and $_.Status -eq 'Online')}|Select Farm,DisplayName,Address,Role

Note: the Role will help you identifying a WFE from and application Server, for example. The address is the real host name used for network connectivity while the Display Name is, like its name suggests it, the text used for displaying the Central Admin.

And cut!

PS: Finally my “assistant director” Anthony (the Minghella of PowerShell, the Hopkins of automation or should I say, the Zuiker of scripting;)) has finally caught his digital pen to shoot ahem.. I mean write, his first post. Welcome online Antho!

Starting a blog is not an easy task. Marc has been harassing me for months to write some posts related to Powershell. My knowledge is still limited and I am far from being a master (I will introduce myself in another post, this is not my goal today). However my experience is growing. Scripting, scripting, scripting, and again scripting. This is the secret... But were to start? If you don't know anything about Powershell, what would you do to be ready to attend the next Microsoft Winter Scripting Games? Here are some advices for beginners. No big deal. Don't put pressure on yourself, just find your way to become a master.

1. Install Powershell

It may sound stupid as a first tip, but this is something really concerning for a beginner. If you're a real beginner, start with PowerShell version 1, which is still the latest official version.

As pre-requisite, you must have .NET Framework 2.0 installed.

• .NET Framework 2.0
  Go to the following URL and find out what version (x86, x64) matches your environment: http://msdn.microsoft.com/en-us/netframework/aa731542.aspx
• PowerShell v1
  Go to the following URL and find out what version (x86, x64) matches your environment:
  http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

When you start to have more experience, you can start to think about PowerShell version 2. The CTP3 was released some weeks ago and we will cover some new cmdlets (abbreviation of “commandlet”, that you can translate as a “function” or command for now…). .NET Framework 2.0 is required. However, if you want to take advantage of the new features, such as Integrated Scripting Environment (ISE) and Out-GridView, you should install .NET Framework 3.5 Service Pack 1.

• .NET Framework 3.5 Service Pack 1
  Go to the following URL and find out what version (x86, x64) matches your environment: http://msdn.microsoft.com/en-us/netframework/aa731542.aspx
• PowerShell v2 CTP3
  Go to the following URL and find out what version (x86, x64) matches your environment:
  http://www.microsoft.com/downloads/details.aspx?FamilyID=c913aeab-d7b4-4bb1-a958-ee6d7fe307bc&DisplayLang=en

If you want to use remoting features of the v2 CTP3, you will have to install the following component (still Beta at the time of writing the post)

• WinRM 2.0 CTP3
  https://connect.microsoft.com/wsman
  This will be covered in a later post.

2. Find some (free) good Documentation

• "Windows Powershell" and "Administrative tasks using Windows PowerShell" free ebooks by Frank Koch : http://blogs.technet.com/chitpro-de/archive/2008/02/28/free-windows-powershell-workbook-server-administration.aspx
  Frank is an Infrastructure Architect in the Technet team in Switzerland (BERN) . This is an amazing source for beginners. It permits to give a good overview of different possibilities that PowerShell provides. Definitely my favorite resource!!
  Don't thank me, thank Frank! Go and download them and read them directly. They even contain workshops.

• Windows Powershell SDK
  - Online version: http://msdn.microsoft.com/en-us/library/cc136763(VS.85).aspx
  - Downloadable version : http://www.microsoft.com/downloads/details.aspx?FamilyID=c913aeab-d7b4-4bb1-a958-ee6d7fe307bc&DisplayLang=en for the SDK of the Powershell v2 CTP3

• Microsoft Technet Script Center: Scripting with Windows PowerShell: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
  Have a look at the URL: "../msh.mspx". For the story, you have to know that the code name for PowerShell was initially Monad. Maybe you wonder why? (answer: http://en.wikipedia.org/wiki/Monadology)

• Microsoft Webcasts at http://www.microsoft.com/technet/scriptcenter/webcasts/ps.mspx

There are a lot of other interesting docs available, for free or not… start with those ones and share any other you find interesting with us!

3. Get an Editor and start to write your first Scripts

Powershell is a shell… but also (mostly?) a scripting language. And to write your scripts, you need a good editor (even if in fact Notepad is enough to start!). Here is a quick selection of some editors I tried and really liked. Download them, evaluate them, and make your choice. You have to feel comfortable to create your scripts.

First of all, the free editors…

• PowerGUI: http://www.powergui.org
  PowerGUI just rocks! It’s a, FREE, very nice-looking editor with a bunch of nice features and it permits to create “Powerpacks”, collection of nodes and functions to extend the PowerGUI console. Just have a look at the screencast tutorial and you’ll find that amazing. I will certainly propose some Powerpacks in the future. 
   
• PowerShell Analyzer: http://www.powershellanalyzer.com/
  One of the first Powershell editor. Haven’t worked with it for a long time but it was nice to work with. Very interesting features too. 
  
  
• PSPad: http://www.pspad.com/
  This my favorite free multi-languages editor. It contains a lot of cool features and color definition for Powershell can be downloaded.

And for the lucky ones who can afford commercial applications, the two following can be natural choices. I anyway invite everybody to download the trial versions, just to have an idea if the features they propose are worth the cost for you and your company or not (and I believe they generally are!). Both following tools have different version (standard, professional, enterprise) and provide great features like color coding, auto-completion, sample scripts, WMI/ADSI wizards, forms builder, logon script builder, etc.

• Primalscript: http://www.primalscript.com/
  
  
• AdminScriptEditor “ASE”: http://www.adminscripteditor.com

Let’s stick to those ones for now; we’ll propose other competitors in a future post, including extended comparison.

4. Convert from vbs

Learning a (scripting) language is not an easy job and it is difficult to have a “starting point”. If you’re already a scripter, mainly in vbscript, I would suggest you to start converting the scripts you already created. For that purpose, you must absolutely add the following link to your favorites “The VBScript-to-Windows PowerShell Conversion Guide”:
http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/default.mspx

5. Time for discipline!

And from now, if you have to create new scripts, don’t use vbscript but do it directly in Powershell: “yes boss, it can take me 10min to write it in vbs and 2 hours in Powershell... but that's the future... Do it in Powershell or die…“

6. Find some goals and projects to work on with Powershell

Go the scripting games webpage of last years and use the competition as training:
http://www.microsoft.com/technet/scriptcenter/funzone/games/default.mspx

7. Ask the experts, read their experiences

Woody Allen is the master of one-liners. You can become the Woody Allen of Powershell if you carefully listen to the wise and experienced guys. I’m far from being part of this restricted club but believe me, I do respect them a lot!

• Blogs
  - Windows Powershell Blog: http://blogs.msdn.com/powershell/
     Microsoft Powershell team official blog, mainly represented by Jeffrey Snover, Windows Management Partner
     Architect
  
  - BS on Posh: http://bsonposh.com/
     Brandon Shell is the one. Any of his comment/post is interesting and clever.
  
  - Dmitry’s PowerBlog: PowerShell and beyond: http://dmitrysotnikov.wordpress.com/
     The creator of PowerGUI has a lot of energy and shares a lot of knowledge.
  
  - The PowerShell Guy: http://thepowershellguy.com/blogs/posh/
     Marc, nicknamed /\/\o\/\/, was one of the first guy to blog about Powershell on the Internet. He started a series
     of “Hey Powershell guy!”, using the concept “Hey Scripting Guy!” concept for Powershell.
     You also want to have a look at his Powertab tool.
  
  - get-powershellblog: http://marcoshaw.blogspot.com/
     Marco Shaw is an MVP from Canada. He’s been blogging for a long time now and is proposing very
     interesting podcasts, where you can find interviews of different Powershell stars!
  
  - Richard Siddaway's Blog "Of PowerShell and Other Things": http://richardsiddaway.spaces.live.com/
     Active member of the UK PowerShell User Group, Richard proposes a nice series of very short posts that permit
     to get interested in some features or cmdlets

• Discussions
  - Use a newsgroup reader client and subscribe to “microsoft.public.windows.powershell”, ask your questions
     or just read the news. Always interesting.
  
  - Windows PowerShell Technet forum: 
     http://social.technet.microsoft.com/Forums/en/winserverpowershell/threads
  
  - The Official Scripting Guys Forum! at http://social.technet.microsoft.com/Forums/en/ITCG/threads/
     Ever been to the Script Center? You know, http://www.microsoft.com/technet/scriptcenter/. If your answer is
     "yes," you know what to do. Dive in and help somebody! If your answer is "no," welcome to our fun little world!
     We'd recommend that you first head over to the Script Center, get your feet wet, and then come back to either
     ask or answer questions. We can't be everywhere at once (I know--shocking!), so we will appreciate any and all
     help you can give to each other to get scripting problems solved. The Microsoft Scripting Guys

8. Script, script, script… and when you’re done, script again!

No choice. If you want some experience, you have to script. And improve your existing scripts. Otherwise you will forgot what you learned. That’s pity , but it’s fact.

In the next post, we’ll cover some additional things you can learn or use to be more efficient to Powershell, including a short list of books. Open your mind, a new world is coming to you. In the mean time, check all the links I provided, read the docs, train yourself, and… You're ready for the next Winter Scripting Games :-))

There are multiple methods to achieve this but since today it’s Friday and I’d like to watch Cloverfield’s making of before midnight :), here are two quick’n simple methods:

Method 1: Using WebDav and NET USE

Conditions: this method will work only if SharePoint is running on port 80, does not use form-based authentication and if the WebClient service is running on your client PC (or server, on which it is set to manual startup mode!)

Start PowerShell and enter the command

net use Z: “http://WSSSERVER/Site01/DocLibName/"

Then simply use the copy command:

copy c:\demofile.txt Z:\

Say what? Use PowerShell for that? It couldn't it work with a standard Windows command-prompt? Yes it can :)

Method 2: Using a standard HTTP “PUT”

Conditions: SharePoint should be configured to use form-based authentication, although the code could be adapted to support it.

Let’s use a function to tidy up the code…

Function UploadToSPDocLib($LocalPath,$spDocLibPath)

{

$WebMethod = "PUT"

$UploadFullPath = $spDocLibPath + $(split-path -leaf $LocalPath)

$WebClient = new-object System.Net.WebClient

$WebClient.Credentials = [System.Net.CredentialCache]::DefaultCredentials

$WebClient.UploadFile($UploadFullPath, $WebMethod, $LocalPath)

}

UploadToSPDocLib "c:\demofile.txt" "http://WSSSERVER/Site01/DocLibName/"

While I still have other interesting ways to upload files to SharePoint, it will be the subject of another post…

And cut!

All product based on SharePoint technologies come with a built-in logging engine named Unified Logging System (ULS). It allows the applications and related component (Microsoft or third-parties) to log activity to the Windows application Event Log and/or to a log file on each server running SharePoint.

Log Location

The log files are, by default, located under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS, the file names always start with a prefix consisting in the name of the server they were generated on: <servername>-<output-format>.log.

Depending upon their configuration, some event may also be logged in the Windows Application event log.

Configuration

To change the location of the log files, the following PowerShell script can be used:

[VOID][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[VOID][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")
$SPDiagnosticsService = [Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local
$SPDiagnosticsService.LogLocation = "G:\Logs\"
$SPDiagnosticsService.Update()

To change the number of log files to be maintained, you can set the “LogsToKeep” property:

Beware: as soon as the Update() method is invoked, the log files above the value specified will be deleted!

Note: this correspond to the setting stored in the registry at the following location: HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS. You might therefore therefore be tempted to edit it directly but MS discourage to do so and recommended to use the SharePoint API instead.

To list/set the verbosity level of each component, STSADM can be used:

To list all level (including hidden ones): stsadm.exe -o listlogginglevels [-showhidden]

To set the level for a given category: stsadm.exe -o setlogginglevel   [-category < [CategoryName | Manager:CategoryName [;...]] ] {-default | -tracelevel < trace level setting> [-windowslogginglevel] <Windows event log level setting>}

More information:

• http://technet.microsoft.com/en-us/library/cc262191.aspx
• http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spdiagnosticsservice.aspx

Log File Format

The log files expose the following fields:

• Timestamp: Equivalent to the “TimeGenerated” field in the “Application” event Log
• Process: the image name of the process logging its activity followed by its process ID (PID) between parentheses. Interestingly, IIS worker processes may also log their activity, they are therefore logged under w3wp.exe
• TID
• Area: This maps the “Source” field in the “Application” event Log
• Category: this maps the “Category” field in the “Application” event Log
• EventID: A unique internal Event ID
• Level
• Message
• Correlation: may contain a link to the the EventID of another logged event

Exploitation/Analysis

There are multiple ways to analyze ULS logs, such as:

• Using the good old notepad, which is a valid option when your servers are not too busy and if you know when, where and what to look for
• Using the Swiss army knife of log files: MS LogParser, see below for examples.
• Using some interesting CodePlex projects: An extension to the Central Administration web site: http://www.codeplex.com/wssmosslogfilereader or a WinForm-based application (which also makes use of MS LogParser): http://www.codeplex.com/ShrptNinjaToolkit
• [UPDATED] From the MS Office Project Web Log, how to read logs using Excel: http://blogs.msdn.com/brismith/archive/2009/01/04/project-server-2007-reading-sharepoint-uls-logs-with-excel.aspx and http://blogs.msdn.com/brismith/archive/2006/12/14/finding-your-way-around-the-sharepoint-logs.aspx

Some Log Parser Queries applicable to ULS Logs

• Troubleshooting Indexing with ULS Log by Joel Oleson
• ULS Log File Data Mining
• I will also upload my own queries in a near future, so check back this location regularly

More Information

• http://msdn.microsoft.com/en-us/library/aa979590.aspx

And cut!