English:

Few month ago I have introduced RemoteStsAdm, a PowerShell module that enable you to execute StsAdm.exe remotely. StsAdm.exe is a command line administration tools for SharePoint. Unfortunately to run StsAdm, one must log-in to SharePoint server member – since the tool can not be executed remotely. RemoteStsAdm is to answer this problem, allowing admin to execute StsAdm remotely. You can download the source code from MSDN Galery here or read the original article in previous post here. 

Yesterday, I have released ImportPSModule that will easy PowerShell module distribution, allow update notification and configuration. The RemoteStsAdm PowerShell module is now available via NuGet, so that you don’t need to download and extract manually. All will be done seamlessly, and whenever we got script update – you will get notified as soon as you open PowerShell session.

So what do you wait for, open PowerShell session and type following:

Import-PSModule RemoteStsAdm 

You may already know PsGet by Chaliy or PsGet by Anurse for PowerShell module distribution. They have created PowerShell module distribution mechanism with different approach.

Chaliy uses PowerShell script approach and customized module directory. Everytime you want to distribute your PowerShell module, you have to fork his github project to update Directory.xml content. Even tough the instruction in https://github.com/chaliy/psget/wiki/How-to-add-your-module-to-the-directory is very clear, however I think there is risk of incorrect Directory.xml modification.

Anurse uses PowerShell manifest approach and standard NuGet package to download and put module in appropriate location. In this case you can create a NuGet package containing PowerShell files and publish it to NuGet repository. Using his module, you will be able to get PowerShell module from NuGet repository right to your console. I like this approach because it uses standard NuGet package and publishing process. However, sometimes I want to be able to register the new module in my profile. I also want to ensure that I always use latest PowerShell Module package – ie. update local module automatically when there is new module in NuGet repository.

So then, I started to create Import-PSModule a PowerShell script module that will give you functionalities such as:

1. Importing PS Module from NuGet repository
2. Load imported module to current session
3. Register imported module to current user profile or all user profile
4. Un-register imported module from current user profile or all user profile
5. Auto-update imported module when user start PowerShell session

To start using the module, start PowerShell session and type following

(new-object Net.WebClient).DownloadString("http://blog.libinuko.com/wp-content/plugins/download-monitor/download.php?id=1") | iex 

The script will perform following actions:

1. Download latest ImportPSModule from central NuGet repository.
2. Install the package to desired location. If you choose to install in User-Module or Global-Module, all future packages will be installed under Module path. If you choose to install in other folder, then all future package will be installed within installation folder.
3. Load the ImportPSModule to the memory. It will also  download latest NuGet.CommandLine package if you don't have in your system.

So what do you waiting for? Start to install the module and publish your PowerShell module in NuGet repository. But don't forget TAG "PSModule" to your NuGet package.

If you want to validate InstallPSModule.ps1, please click here InstallPSModule (116) .

English

The STSADM.exe is command-line tool for administration of Office SharePoint Server (SharePoint 2007, SharePoint 2010). It is installed on the same location as SharePoint Products and Technologies location: %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin (for SharePoint 2007) or %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\bin (for SharePoint 2010). You must be Farm Administrator to be able to run the tool.

By default, the STSADM.exe must be executed locally since it will access SharePoint Object Model. It is also necessary for the tools to connect to the SQL Database using credential of the user who executes it. Therefore, normally the Administrator must remote-login to the SharePoint server before he/she can run the tools.

Remote execution of STSADM.exe using PowerShell Invoke-Command cmdlet faces double-hop challenges. This occurs when SQL Database for the farms is installed on different machine than the SharePoint server. The credential in theInvoke-Command session can not pass through to the SQL Database without configuring delegation in the WinRM services.This module solve double-hop problem without configuring CredSSP.

Download the module here:
http://code.msdn.microsoft.com/Remote-StsAdm-in-6fec24b8

English

In large network, issuing a command to remote server from current terminal is sometimes necessary. Some propose client-server mode; for example Remote StsAdm (http://netstsadm.codeplex.com/) and other propose to use PsExec (http://thingsthatshouldbeeasy.blogspot.com/2009/08/run-stsadm-commands-remotely.html).

The client-server mode requires installation of 3rd party tools. This kind of installation sometimes (or most of the time) is forbidden by company security policy.
Second option using PsExec from SysInternal (now part of Microsoft) doesn't requires installation to SharePoint server and may be the correct approach. However, I am not convince that this tools will be compatible with the future Operating System.

So, what is the option?
PowerShell and Remoting!

PowerShell has been introduced during Windows 2008 era. However, Windows 2003 server owner can apply KB968930 (http://support.microsoft.com/kb/968930) to bring PowerShell functionality to their server. PowerShell will replace command.com because of the flexibility – enabling integration between shell and operating system itself.

Let's get our job done

1. First enable remoting on the SharePoint Server.

    Enable-PSRemoting -Force

2.  Prepare the stsadm command alias

 $executable = "$env:ProgramFiles\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe" 

3.  Remember my previous post about how to avoid double hop problem? (http://blog.libinuko.com/2011/04/29/powershell-how-to-overcome-double-hop-problem-in-powershell-remoting-2/) . Now we will create new function that uses Invoke-RemoteCommand. Basically, we will construct commandline parameter for Invoke-RemoteCommand. We also try to provide AS-IF user call stsadm.

function StsAdm
{
   param(
      [string] $commandOptions,
      [string] $username,
      [string] $password
   )

   $executable = "$env:ProgramFiles\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe"

   Invoke-RemoteCommand -commandline "'$executable' $commandOptions" -username $username -password $password

}

Usage : StsAdm -commandOptions "-o enumwebs" -username "setup account" -password "setup password"

And voila, you have remote stsadm function without compromising security policy.

English

When I am looking for a way to compress file(s) into Zip, I find a blog from David Aiken here (Compress Files with Windows PowerShell then package a Windows Vista Sidebar Gadget) . I will just focus on Add-Zip function and nothing more.

Here is the original code:

function Add-Zip
{
    param([string]$zipfilename) 

    if(-not (test-path($zipfilename)))
    {
           set-content $zipfilename ("PK" + [char]5 + [char]6 + ("$([char]0)" * 18))
           (dir $zipfilename).IsReadOnly = $false
     } 

     $shellApplication = new-object -com shell.application
     $zipPackage = $shellApplication.NameSpace($zipfilename) 

     foreach($file in $input)
     {
            $zipPackage.CopyHere($file.FullName)
            Start-sleep -milliseconds 500
     }
}

usage: dir c:\demo\files\*.* -Recurse | add-Zip c:\demo\myzip.zip

I am raising two problems with the code:

1. Looking at the usage example, it is clear that the function accept only fully path filename. The reason, on line-12 , the $shellApplication.NameSpace parameter is $zipfilename; and this is not possible without giving fully path filename.

2. On line-16, the operation expect that $input array will contains object with FullName properties, that why the usage example uses DIR. What about if you just want to specify a filename?

With the 2 problem above, I am ready to improve that function. In the new improved version, Get-ChildItem will help us to convert any string representation of a file to a fully path filename. It won’t break DIR piping functionality, since actually Get-ChildItem is dir (and extra) functionality.

Here is the improved version:

function Add-Zip
{
	param([string]$zipfilename)

    $currFile = $zipfilename | get-childitem
	if(-not (test-path($zipfilename)))
	{
		set-content $currFile.FullName ("PK" + [char]5 + [char]6 + ("$([char]0)" * 18))
		(dir $currFile.FullName).IsReadOnly = $false
	}

	$shellApplication = new-object -com shell.application
	$zipPackage = $shellApplication.NameSpace($currFile.Fullname)

	$input | % {
            $file = $_ | get-childitem
            $zipPackage.CopyHere($file.FullName)
            Start-sleep -milliseconds 500
	}
}

usage: "FileInThisFolder.txt" -Recurse | add-Zip "ZipInThisFolder.zip"
        dir c:\demo\files\*.* -Recurse | add-Zip c:\demo\myzip.zip

So, I hope you enjoy the improved version.

English:

I am interesting to the PowerShell remoting topic from PowerShell Cookbook Chapter 29 here (http://www.pavleck.net/powershell-cookbook/ch29.html). In order to solve double-hop problem, it uses schedule task. The sample create schedule task to Enable-PSRemoting in remote machine.

But don’t you think we need something more generic to overcome double-hop problem? PowerShell offers Enable-WSManCredSSP or Kerberos so that the process can delegates the credential to execute next-hop process. However,  CredSSP is only available on Windows 7 and above. What about OS before Windows 7 or Windows Server 2008?  If you have Windows 7 or Windows Server 2008 – you may follow tutorial in this link (http://www.ravichaganti.com/blog/?p=1230). But if you have Windows 2003 or previous version, then you must keep reading.

So, lets start by defining our function Invoke-RemoteCommand. This command will accept :

1. (Optional) Taskname, name of task identifier
2. Commandline, actual command for example powershell or cmd.exe
3. Username, credential to execute the command
4. Password, password for the credential to execute the command

function Invoke-RemoteCommand{

    param(
       [System.String]
       $taskname = (get-date -format "'Demo task' dd-MM-yyyy hh.mm.ss"),

       [System.String]
       $commandline = "cmd /c 'dir c:\'",

       [Parameter(Mandatory=$true)]
       [String]
       $username,

       [parameter(Mandatory = $true)]
       [String]
       $password
   )

    schtasks /create /tn $taskname /tr $commandline /sc weekly  /ru $username /rp $password | out-null
    schtasks /run /tn $taskname | out-null
    write-host "Waiting task execution." -nonewline -foreground green
    do {
      $taskStatus = schtasks /query /fo csv /v | convertfrom-csv | ? { $_.TaskName.TrimStart("\") -eq "$taskname"}
      sleep 10
      write-host "." -nonewline -foreground green
    } while ($taskStatus."Status" -eq "Running")
    write-host "Success!" -foreground green
    schtasks /delete /tn $taskname /f | out-null
    return $taskStatus
}

For example, we want to list directory of the ServerX by issuing command to ServerY. Normally, following command will fail because of double-hop problem (it doesn’t matter whether you supply user credential, it will still failed):

Invoke-Command -ComputerName ServerY -Script { "dir \\ServerX\d$" }

Using the new function, we change the command into

invoke-command -script { Invoke-RemoteCommand -cmd "powershell -noprofile -command 'dir \\ServerX\d$'" -username "domain\user" -password "password" }

The last script will performs following:

1. Create schedule tasks with a specific identifier

2. Command in schedule task is “powershell –noprofile …..”

3. Execute schedule tasks

4. Wait until execution completes

5. Return the status

Finally, the script will work in Windows 2003 , Windows 7, Windows Vista or Windows 2008.

English:

Sometimes you may received a request to change rating icons, from a normal star to a love icon. So, how would you do it?

Figure 1. Original rating icons

Figure 2. Modified love rating icons

1. Find and prepare rating icons.  In this case I will need to prepare 4 styles rating icons

Title	Sample	Size
a. Empty Rating		16×16
b. Selected Rating		16×16
c. Rating Overlay		448×16
d. Rating Overlay RightToLeft		448×16

2. Save the new icons under 14 hive\Images.

3. Create script to modify SPWeb property bag. To ease our job, I will use PowerShell script as follows,

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) > $null

$spSite = new-object Microsoft.SharePoint.SPSite(“http://win2k8″);
$spWeb = $spSite.OpenWeb();

$spWeb.Properties["Ratings_NewRatingIconUrl"] = “/_layouts/Images/love_RatingsNew.png”;
$spWeb.Properties["Ratings_EmptyIconUrl"] = “/_layouts/Images/love_RatingsEmpty.png”;
$spWeb.Properties["Ratings_ImageStripUrl"] = “/_layouts/Images/love_Ratings.png”;
$spWeb.Properties["Ratings_ImageStripRtlUrl"] = “/_layouts/Images/love_Ratingsrtl.png”;

$spWeb.Properties.Update();
$spWeb.Dispose();
$spSite.Dispose();

iisreset

4. Voila ! And you can refresh your browser to see the changes.

5. Finally you can distribute your solution into a solutions package with feature activation events to register/un-register custom rating images.

English

I think you may already know Set-SPServiceApplicationPool. This command can be used to modify apppool account for service application – but it doesn’t work for Web Application. I am looking for Set-SPWebApplicationPool but I can not find it anywhere.

So here is the PowerShell script

param([string] $url, [string] $account)

$SPWebApp = Get-SPWebApplication $url

$SPManagedAccount = Get-SPManagedAccount –Identity $account

$SPWebApp.ApplicationPool.ManagedAccount = $SPManagedAccount

$SPWebApp.ApplicationPool.Update()

English

Today I find a strange behaviour, my Office 2010 can not browse to the SharePoint 2010 document library. In short, I can not save my document directly to SharePoint 2010.  Office 2010 provide Save and Send functionality, which should give me functionality to save directly to SharePoint 2010 as what it does in previous version; so what could be the problem?

Saving to SharePoint 2010 document library requires WebDAV functionality via Web Client service. Unfortunatelly the Web Client service is not enabled by default, and it is part of Desktop Experience features.  So, how can we enable it using PowerShell?

# Open PowerShell console and then type

import-module servermanager
Add-WindowsFeature Desktop-Experience

English

I have found 2 good articles on how work with XML in PowerShell.

http://www.pluralsight-training.net/community/blogs/dan/archive/2006/11/25/42506.aspx
http://www.pluralsight-training.net/community/blogs/dan/archive/2006/11/28/43561.aspx

Don’t be surprised that you will find % notation that represent ForEach-Object.