This project is read-only.

Local Farm Deployment

Aug 28, 2012 at 12:46 AM

Hi, I was reading all options in the input XML and I saw that there is a flag to set if the deployment should be done only in the local server instead of all servers.

I would like to ask if someone use this with success to reduce the deployment outage while deploying farm solutions in a multi server farm. (ex. with 3 WFE)

I read here: http://msdn.microsoft.com/en-us/library/ms466579.aspx that the Local is not recommended:

"Caution

The DeployLocal and RetractLocal() methods should be used only to temporarily deploy or retract a solution from a particular server for trouble-shooting purposes. At all other times, the front-end web servers must be identically configured."

Thank's in advance

Andres

Aug 28, 2012 at 2:02 PM
Edited Aug 28, 2012 at 2:03 PM

Hi Andres,

I suppose you are refering to that setting?

<!-- Specifies if checks and actions should be run on all servers in the farm or only the local server -->
<!-- ! Make sure that the deployment account is local administrator on all servers -->
<!-- ! Make sure that PowerShell Remoting is enabled on all servers and the deployment user is permitted-->
<!-- ! This can be done by running 'Enable-PSRemoting -Confirm:$false' -->
<IncludeAllServersInFarm>true</IncludeAllServersInFarm>

Maybe I have described it a bit unclear.
The solutions are always deployed to the entire farm, because, as you have mentioned, only deploying to one server in the farm is not recommended and wouldn't solve the purpose of this script :-)

The setting above refers only to actions which are done after the deployment/retraction/update process namely:
- Restart SPTimerV4, SPAdminV4, SPUserCodeV4
- IISReset
- RecycleAppPools
- WarmupUrls

 If you set <IncludeAllServersInFarm>false</IncludeAllServersInFarm> then these actions will be performed only on the machine where you run the deployment script. If you set <IncludeAllServersInFarm>true</IncludeAllServersInFarm> then SPSD will attempt to access all servers in the farm which have the ServerRole!="Invalid"  through PowerShell remoting and run the actions also on these servers. The WarmUpUrls action will create a local proxy on each server to warmup the urls on each separate WFE.

In order to use <IncludeAllServersInFarm>true</IncludeAllServersInFarm> on all servers PS-Remoting has to be enabled, the deployment account requires PS-Remoting access (usually only granted for local admins) and the LoopBackCheck has to be disabled (in order to create the local proxy for warming up the urls).

I hope that clears things up a bit.

BR

Matthias

 

Jan 23, 2013 at 1:19 PM

Just a quick update.

The setting

<IncludeAllServersInFarm> has been renamed in release 4.1 to <RunOnMultipleServersInFarm>

Possible values are "OnlyLocal", "All", "WebFrontEnd" or "Application" which refer to the role of the servers which are member of the farm.

If the setting is not present, the default "OnlyLocal" will be used.

Sep 26, 2014 at 2:08 PM
Edited Sep 26, 2014 at 2:15 PM
Hi Matthias,
it looks like, that the option "OnlyLocal" is not yet implemented in a way that it really supports deploying or updating on the local server, by using the Attribute "-local" with install-spsolution or update-spsolution.

I would propose something like that to fix the issue ...

@line1583 in SPSD_Deployment.ps1
#########################################################################################
#modified by thomas.radman@hotmail.com to enable variations for the Update-SPSolution Command 
[scriptblock]$UpdateCommand = {
Update-SPSolution -LiteralPath "$solDir\$solutionName" -Identity $solutionName -GACDeployment:$AllowGACDeployment -force:$force -Confirm:$false
}
if ($conf.Settings.RunOnMultipleServersInFarm -ieq "OnlyLocal"){
    $LocalAttribute = [scriptblock]{ -Local}
}
if ($SPSD.InstalledVersion -eq 14){
force:$force -Confirm:$false
    $UpdateScriptBlock = [scriptblock]::Create($UpdateCommand.ToString() + ([scriptblock]{ -CASPolicies:$AllowCASPolicies}).tostring() + $LocalAttribute.tostring())
}
elseif ($SPSD.InstalledVersion -eq 15){
    if($solution.ContainsWebApplicationResource){
GACDeployment:$AllowGACDeployment -force:$force -Confirm:$false
        $UpdateScriptBlock = [scriptblock]::Create($UpdateCommand.ToString() + ([scriptblock]{ -FullTrustBinDeployment:$AllowFullTrustBinDeployment}).tostring() + $LocalAttribute.tostring())
    }
    else{
        $UpdateScriptBlock = [scriptblock]::Create($UpdateCommand.ToString() + $LocalAttribute.tostring())
    }
}
Invoke-Command $UpdateScriptBlock
#######################################################################################
(the + should be the "plus"-sign)

I hope that makes sense

kind regards
Thomas
Sep 26, 2014 at 2:43 PM
Hi Thomas,

thanks for the feedback. As described above the "OnlyLocal" setting is named a little bit unclear.

It is actually meant to tell SPSD only if the post deployment actions should run only on the machine where I execute the script, or if SPSD should PS-Remote into the other machines on the farm to perform these actions.

The WSPs are meant to be deployed to all servers in the farm in both cases.

What you are referring is something I was looking in too, in order to reduce the downtime of the individual servers. But I have never implemented it as it has some major implications.

Naturally deploying only on one server of the farm would render the different servers out of sync regarding the customisations. So they would need to be updated one by one which may cause undesired problems (e.g. if one server deployment fails).
Still one could add another flag for this purpose in the environment xml file.
Note, also Deploy-SPSolution and Retract-SPSolution would need to implemented in a similar way like your example.

I have never tested this in real life though and rather relied on the standard farm deployment mechanism where SP takes care of the WSP distribution itself.
Still, if you are interested to take on that task, please fork the source at
https://github.com/rencoreab/SharePoint-Solution-Deployer
And send a pull request with the changes :)
I am happy to assist.

The scripts are located in the SPSD.Script VS Project and a new ready-to-use SPSD package is created in its bin directory after build for testing.

Looking forward to hear back from you.

Matthias