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

Remember about critics to “stsadm –o copyappbincontent” to deploy SharePoint resource in my previous post here.

At the end of the post, I think that it should be “stsadm –o copyfarmappbincontent” instead.

Why?
Because the last will work in centralized deployment mode, same as solution deployment.

But what’s the secret? Why the standard copyappbincontent doesn’t work in farm configuration?

I’ll post in another article. But now, I have created the project in Codeplex. You can grab the code or download the binary here.

English

When you start to work with localization in SharePoint, I believe that you may end with one of Mikhail Dikov proposal here or here .

Partially I agree with his proposal, to leverage the resource deployment through the UI. However, his strategy may fail when you apply to server farm architecture with multiple Web Front End (WFE).

You have to go to every WFE, and activate/deactivate the feature before you can get it deployed in all WFE. The same concept as standard SharePoint’s stsadm command,

stsadm –o copyappbincontent

That command, instruct local SharePoint server to copy resources, sitemap etc. to web all application folder, except the Central Admin webapps.

And still we have big problem, that we have to run that command in every WFE.

I can say this is a big problem, because it against the concept of centralized deployment of WSP. Imagine, if you’re system administrator who wants to have WSP to automate distribution of artifact – and now you are facing a fact that since the WSP contains resources; you don’t have the centralized deployment concept anymore.
After doing

stsadm –o addsolution

stsadm –o deploysolution

in one of WFE – then you have to go through all WFE to execute

stsadm –o copyappbincontent

to deploy resources to webapps.

I know that some system administrator / production team, so we have to solve this problem. May be change it to stsadm –o copyfarmappbincontent , to perform appbincontent deployment in farm architecture.