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

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:

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

You may already read this following article “Writing Custom Web Service for SharePoint Products and Technologies” (http://msdn.microsoft.com/en-us/library/dd583131(v=office.11).aspx) or “Walkthrough: Creating a Custom ASP.NET Web Service” (http://msdn.microsoft.com/en-us/library/ms464040.aspx). The steps can be summarized as follows:

1. Create normal ASPNET web service
   In this step you will create ASPNET Web Services using Visual Studio as you always do. From this step, you will have <Service>.asmx, where <Service> is your web service asmx file.
2. Create corresponding .disco file and a .wsdl file
   In this step you will create extract of DISCOvery  file and WSDL of ASPNET web service from step #1, and add reference to Microsoft.SharePoint assembly. From this step, you will have 2 files <Service>disco.aspx and <Service>wsdl.aspx.
3. Copy the 3 files to _vti_bin (12hive\ISAPI)
   In this step you will copy the 3 files (<Service>.asmx, <Service>disco.aspx and <Service>wsdl.aspx) into 12hive\ISAPI. Of course in real deployment, you can use WSP.
4. Register the new web service in spdisco.aspx
   In this step you will modify built-in SharePoint file spdisco.aspx, so that your web service will be recognized by SharePoint.

Until here you will have working custom web service in SharePoint but  are you sure that your SharePoint farm is still supported?

If you read “Modifying Built-In SharePoint Files” (http://msdn.microsoft.com/en-us/library/bb803457(v=office.12).aspx) rules, the step #4 is unsupported. Step#4 is to modify spdisco.aspx so that the custom web service will work.

So do you still want to built custom web service using that technique?
My suggestion, think twice! In fact you can still use ASPNET web service without SharePoint integration – it will work but lost SharePoint context. Moreover, you can’t tell WSP to modify spdisco.aspx unless you use event handler – which mean more complexity.

English

In the previous version, creating cascading lookup field was becoming a problem. At least 2 or more technique have been proposed for example using Javascript , or custom field. In this video cast, I will continue the InfoPath and SharePoint 2010 productivity series by implementing the cascading lookup field using InfoPath. In this video, I will extend Members list with City – Province – Country , information. Province and Country are cascading lookup field.

Update:
See other post on How to create Cascading Lookup Field using Client Object Model.