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 (115) .

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

Before we continue, I suggest you read the first part here ; it gives basic idea of how it works. The purpose of part-2 is to make real implementation of Custom Web Service , but it is not the only way to do it. There are some key points that I want to show here:

1. We will put our custom Web Services in a Custom folder under _vti_bin. In this case we will create new folder WSCustom under (12hive/ISAPI for SharePoint 2007 or 14hive/ISAPI for SharePoint 2010)
2. We will need a helper to read SharePoint context (SPVirtualPath) before passing the request to the real ASMX. In this case we will copy WSDISCO.ASPX  and WSWSDL.ASPX from original _VTI_BIN to _VTI_BIN/WSCustom folder
3. We will need custom SPDisco.aspx for our web services, in this case I will name it WSCustomSPDisco.aspx. This is the file, where we will register our web service. (Note the registration is optional, but it is required for truly SharePoint integration)
4. We need an interceptor so that request to SPDisco.aspx will return combination between original SPDisco.aspx and WSCustomSPDisco.aspx. In this case, we will create WSCustomHttpHandler that combine XML from the two files.
5. We need rules to add rules to redirect request to _vti_bin/spdisco.aspx to our WSCustomHttphandler.

In the diagram, the scenario will look like this

1. Create ASPNET Web Services using Visual Studio. 
   You can follow instruction in MSDN here (http://msdn.microsoft.com/en-us/library/dd583131(v=office.11).aspx) and stop until “To copy the Web service files to the _vti_bin virtual directory”).

2. Create custom folder for your project under _vti_bin (for example 12hive/ISAPI/CustomWS for SharePoint 2007 or 14hive/ISAPI/CustomWS for SharePoint 2010). In this custom folder, we will put 3 files for every web service (*.asmx) which are:
   • <service>.asmx , where <service> is your web service file.
   • <serviceDISCO>.aspx , where <serviceDISCO> is corresponding DISCO file of your web service.
   • <serviceWSDL>.aspx , where <serviceWSDL> is corresponding WSDL file of your web service.
     
3. Copy ISAPI\spdisco.aspx to ISAPI\spdisco.disco.aspx . We need copy of original spdisco.aspx, since we don’t want to have infinite loop in our HttpHandler later.
4. Create ISAPI\customws.spdisco.aspx. In this file, we will register our custom web service. This is important to avoid modifying SharePoint built-in file.
5. Create HttpHandler to combine content of spdisco.aspx and *.spdisco.aspx.
6. Register HttpHandler in web.config. We will intercept all _vti_bin/spdisco.aspx with our HttpHandler.

More Information

1. Tutorial video, Writing Custom Web Services for SharePoint in Supported Mode.
   [See post to watch Flash video]
    
2. Download source code for this article Visual Studio 2010 + SharePoint 2010 (http://code.msdn.microsoft.com/Writing-SharePoint-Web-in-cb9de1be)

English

If you have read my comments on the Writing Custom Web Service for SharePont, Is it supported here (http://blog.libinuko.com/2011/02/16/sharepoint-writing-custom-web-service-for-sharepoint-is-it-supported/) ; you may have already created standard ASPNET web services. It is working, but with some limitation:

1. You can not have path virtualization

   Virtualization is one of SharePoint’s technique provided by SPVirtualPath provider, that enable virtualization of your web service path. For example, list.asmx will be available for http://mysite.com/_vti_bin/lists.asmx , or http://mysite.com/sites/myothersitecollection/_vti_bin/lists.asmx. The site collection has been virtualized by SharePoint.

   Without virtualization any web service consumer will have to access to the same path, usually in the root; for example /_services/mywebservice.asmx">/_services/mywebservice.asmx">http://<webapps>/_services/mywebservice.asmx

2. You can not have SPContext

   SPContext is very powerful object in SharePoint development. Using this context, we can retrieve current SharePoint context without having to instantiate it. For example, you can get current SPWeb by calling SPContext.Current.Web – and you don’t need to dispose it (in fact you’re not suppose to dispose it). Still using SPContext you can have direct access to list and everything under SharePoint.

   Without having direct access to SPContext, you have to instantiate SPWeb or SPSite using normal constructor with URL as parameter. It means new SPSite/SPWeb thread in the server memory, and you have to dispose it once you’ve done working with it.

So, how can we write custom web service for SharePoint in supported mode?

Before we start, we have to understand SharePoint architecture and how does the processing works for web services. I take following picture from SharePoint Architecture in MSDN. It describe how SharePoint process our request. There is SPHttpApplication which has SPRequestModule and any additional ASP.NET Module; and before the request returned back to the user SPHttpHandler is doint the job.

How SharePoint process web services?

If we dig into into the process on how SharePoint process request to web services in _vti_bin.

There are 3 scenarios of http request to the web services,

1. Disco request, identified by suffix ?DISCO in the web service address. For example, */_vti_bin/list.asmx?Disco
2. WSDL request, identified by suffix ?WSDL in the web service address. For example, */_vti_bin/list.asmx?Wsdl
3. Web service post request. For example, */_vti_bin/list.asmx?op=GetListItems

Every request will be processed by SPHttpHandler (SharePoint) and ScriptHandlerFactory (system.web.extension), but the SPHttpHandler will be selective only for Disco and Wsdl request.

On disco/wsdl request, SPHttpHandler will transfer the request to wsdisco.aspx or wswsdl.aspx using Server.Execute operation. This operation ensure that wsdisco.aspx/wswsdl.aspx is receiving same request object. wsDISCO.aspx or wsWSDL.aspx will then instantiate SharePoint Context object. Any *.aspx will be successfully instantiate SharePoint context object because they are managed by SPHttpApplication and hence it also impacted by SPVirtualPath provider from SharePoint which will activate path virtualization.

Next, wsDISCO.aspx will transfer the request to the <service>DISCO.aspx and wsWSDL.aspx will transfer to the <service>WSDL.aspx – using Server.Execute operation. So here we have seen 2 transfer operation. At the end, the result is correct WSDL/DISCO request. The correct WSDL/DISCO will point to the correct virtual path of the request. (Remember how do you create <service>disco.aspx / <service>wsdl.aspx)

When a consumer use the contract and tries to consume it. The SPHttpHandler will no longer intercept the request, but the normal ScriptHandlerFactory from System.Web.Extensions. However with the correct path in disco/wsdl, now the asmx now have the ability to look into current context from SharePoint. And hence you will be able to use SPContext.Current.Web in custom web services.

Part-2 is how to start create custom web services. I will need help from my buddy Denni , he will code for me. –

References

1. Writing Custom Web Services for SharePoint Products and Technology (http://msdn.microsoft.com/en-us/library/dd583131(v=office.11).aspx)

2. SharePoint Architecture (http://msdn.microsoft.com/en-us/library/bb892189(v=office.12).aspx )

3. Architectural Overview of Windows SharePoint Services (http://msdn.microsoft.com/en-us/library/dd583133(v=office.11).aspx)

4. Modifying Built-In SharePoint Files (http://msdn.microsoft.com/en-us/library/bb803457(v=office.12).aspx)

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:

Some of you may be not aware that we can use SharePoint List for Visio Diagram data source. So how can we configure SharePoint List for Visio Diagram data source?

Following steps demonstrate how to do it using SharePoint 2010 and Visio 2010, however it also applies to SharePoint 2007 or Visio 2007.

Step-by-step

1. Open Visio (.vsd) file.
2. On Data tab, and  Link Data to Shapes.

   

3. On  Data Selector window, choose Microsoft SharePoint Foundation list.

   

4. Type SharePoint website URL

   

   Note: Enter username and password combination if necessary.

   

5. Choose SharePoint list that you want to use, then click Next and Finish.
   
   
6. You will return to the main Visio diagram with data table from SharePoint list. Then you can use the table (linked-to-SharePoint List) as data source for your diagram.

   

Source: http://social.technet.microsoft.com/wiki/contents/articles/4225.aspx

English

There are some webcast about Microsoft Project 2010 Solution Starters. It demonstrate the power and extensibility of SharePoint 2010 and Project 2010. Find out yourself on user experience series and code walkthrough here:

User experience series:

1. Microsoft Project 2010 Solution Starters – User Experience #1
2. Microsoft Project 2010 Solution Starters – User Experience #2

Code walkthrough:

1. Microsoft Project 2010 Solution Starters Drilldown & Code Walkthrough #1
2. Microsoft Project 2010 Solution Starters Drilldown & Code Walkthrough #2
3. Microsoft Project 2010 Solution Starters Drilldown & Code Walkthrough #3
4. Microsoft Project 2010 Solution Starters Drilldown & Code Walkthrough #4

So , are you dare to take the challenge and move to the new platform?

English

A few days ago, Microsoft has released Service Packs 1 for SharePoint 2010. As usual, the installation must follow general rules of installation order:

1. SharePoint Foundation
2. SharePoint Foundation Language Packs
3. SharePoint Server 2010
4. SharePoint Server 2010 Language Packs

And if you have SharePoint Server 2010, you can run SharePoint Configuration Wizard after completing installation of all service packs. You can skip SharePoint Configuration Wizard on installation order 1-3.

If you have multiple servers in a farm, make sure that you have perform the installation in all servers before kicking-in SharePoint Configuration Wizard in the server.

More information from the team blog : http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=984

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.