Closed pcsswamin closed 4 years ago
We have many deployments in our organization and debated the 3 known options to apply patches to existing systems: 1) Good ole fashioned manual execution 2) Powershell Desired State Config (PSDSC) 3) Alternative Means
Option 1 is an option (and the default approach if nothing else), but quickly becomes unsustainable with the amount of environments we manage. Plus, confidence is not high that all systems will be included
Option 2 seems overly complex to apply a patch and has a few challenges (both related to our design choices and our organization policies). Many of our portals have IWA enabled, so we would have to disable Windows Authentication on all the portal solutions prior to executing PSDSC to apply the patches (design decision).
Furthermore, running a full 'upgrade' to get the patch applied will go through all the test/execute steps for a typical PSDSC execution which is not very efficient. If there was a "Mode" for 'patch' then this becomes much more palatable (and I think best case result of this 'issue' is to ask for an enhancement to support a patch only execution mode with a list of systems).
We also scrub our .json files clean of sensitive information (like account credentials) as they change every 60 days per our IT Security policy, so getting these most recent passwords back into the .JSON files is somewhat challenging for doing an organization wide patch deployment. We have to do this for 'site by site' upgrades already.
So we ended up with Option 3 using just a stand alone powershell script. There are other options to consider as well (just google 'patch management').
Here is a rough script we used on the last 10.7.1 Security 2019 Update2 patch (the servers.txt is expected to be a list of hostnames to apply the patch to, 1 hostname per line):
$sourcefile = "\\<server>\<share>\ArcGIS-1071-S-SEC2019U2-Patch.msp"
$Computername = Get-Content C:\tmp\servers.txt
#-----------------------------------------------------------[Execution]------------------------------------------------------------
foreach ($Computer in $computername)
{
Write-Host "`n"
Write-Host -ForegroundColor Green "Starting Install..."
Write-Host -ForegroundColor Cyan "Creating Folders on remote computer"
$destinationFolder = "\\$computer\C$\Esri_1071_patch"
if (!(Test-Path -path $destinationFolder)) {
New-Item $destinationFolder -Type Directory
}
Write-Host -ForegroundColor Cyan "Copying files to remote computer"
Copy-Item -Path $sourcefile -Destination $destinationFolder
Write-Host -ForegroundColor Cyan "Installing patch"
Invoke-Command -ComputerName $computer -ScriptBlock { cmd /c start /wait Msiexec /p c:\Esri_1071_patch\ArcGIS-1071-S-SEC2019U2-Patch.msp /log c:\Esri_1071_patch\AGSPatch2019U2.log }
Write-Host -ForegroundColor Green "Installation Complete for $computername"
}
Moving forward, we will continue refining this script as a more automated way of deploying patches without the overhead of the PSDSC utilities. We also add the Esri patches to our PSDSC defined "PatchesDir" (\\\<server>\\<share> in the referenced script above) folder so that new installs (and upgrades) from PSDSC execution will receive the patches.
Hope this helps..
Patrick @pfoppe ,
Your comments are welcome.
Option 3 (Plain PS) is not idempotent. Idempotency is an important requirement for our automated operations for creating identical, repeatable environments. Use of Chef, Ansible and PS DSC is increasing due to this reason. Even this esri ps dsc module we are discussing potentially was created due to that reason.
Option 2 (PS DSC): In an ideal scenario, every step you would need to do before patching and after patching will need to be coded up in corresponding custom dsc resource and configurations. It might seem utopian considering all the hurdles but many IT devops efforts are striving towards that.
Option 2 - In the short term, I would request the esri team to consider spending some time on patch deployment. Outside of installation, this is one of the most common and important use case for any organization trying out the ArcGIS DSC module. Some immediate needs are
Side note: Portal adoption by many organizations will be difficult if idempotent deployments are not easy to implement.
Automated, idempotent software deployment and maintenance is a requirement in my organization. I think it is becoming a very high priority across the IT landscape.
You are correct that option 3 that we are using is NOT idempotent
However, it has been the easiest and most standard approach we have used for us to execute the patches across our stack.
I had an old Project Manager that often times reminded us not to "use a bazooka to swat a fly" We have struggled to setup PSDSC for patches (with all the overhead and complexities involved to run PSDSC). We are hoping we can see a benefit during new deployments and upgrades with PSDSC, but do NOT see enough value using PSDSC for our patches.
Please try with v3.0.2. -Mode Install
and -Mode InstallLicense
is now supported for this deployment type.
I tried repurposing 'SampleConfigs/Gis Servers/GISServer-GeneralPurpose-MultiMachine.json' to apply patches to multiple ArcServer machines like below. But I got an error as ArcGIS DSC module was assuming that I am doing an HA deployment.
"AllNodes": [ { "NodeName": "machine1", "Role": [ "Server" ] }, { "NodeName": "machine2", "Role": [ "Server" ] }, { "NodeName": "machine3", "Role": [ "Server" ] }, { "NodeName": "machine4", "Role": [ "Server" ] } ],
Applying patches to multiple servers is a common use case. Hope this can be considered as an enhancement.