Licensing ArcGIS Server in secure cloud subnet

Question

Hiya, We're trying to deploy ArcGIS Enterprise 10.7.1 through the azure cloudbuilder with a rather secure (sub)net which is in control of our CSP. The deployment currently fails on: "error": { "code": "ResourceDeploymentFailure", "message": "The resource operation completed with terminal provisioning state 'Failed'.", "details": [{ "code": "VMExtensionProvisioningError", "message": "VM has reported a failure when processing extension 'DSCConfiguration0'. Error message: "DSC Configuration 'ServerConfiguration' completed with error(s). Following are the first few: PowerShell DSC resource ArcGIS_License failed to execute Set-TargetResource functionality with error message: [ERROR] - Attempt 10 - Licensing for Product [Server] failed. Software Authorization Utility returned Error authorizing with the following file C:\Packages\Plugins\Microsoft.Powershell.DSC\2.80.0.0\ArcGISGISServerAdvanced_ArcGISServer_USER.prvc The SendConfigurationApply function did not succeed."." }] }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ It seems (no RDP, so quite limited in deep diagnostics...) that ArcGIS is unable to license ArcGIS Server. Now our CSP works with a DNS-based whitelist on what kind of resources the individual machines can reach over the internet (funny due to this deployment getting a public IP itself...). I validated that the file is correct, it's from a fresh dev subscription and works in a deployment without the CSP subnet... I already told our CSP to whitelist *.esri.com; however, still no luck. My question: What resources does the server licensing use which we need to whitelist? This is not documented (internal server resources tend to be documented only, or a non-cloud builder supported 'offline' authentication), and our new CSP is also not really forthcoming in deep traces on what happens...

Anonymous User · Answer

Hello Randall, yeah... I thought so. Whilst software authorization ís poorly documented regarding in comparison to the rest of the ArcGIS platform (not my first "weird IT partner" deployment this...), those were the ones I told them to whitelist... yet still... no authorisation, with the ARM in azure (and cloudbuilder itself, after about 45min...) throwing above json as the exception. An exception they don't throw when we don't use the CSP provided network but our own created (but yeah, obv, at that point no databases for our poor GIS-poc).

We're trying to achieve a cloud-native deployment here. Our company (about 1807 ArcGIS users) is moving from on-prem to PAAS/IAAS. Our goal is to have a cloud-native deploy (using the supported and provided azure images provided by esri, like these: ArcGIS Enterprise 10.7.1 ), which leverages the whole 'seperation of application/config', using azure storage accounts and OMS for the GIS itself rather than drives and shares... We had luck with this before (and it made platform lifecycle management a breeze...), just not with this CSP, who for some reason feels like having to whitelist everything on the internal networks... I mean... the application has an endpoint in the form of a public IP...

Although I hoped to avoid it because to aside myself, a team also has to work with it (the list of changes we had to make for other parts where cloudbuilder failed is already getting to be not quite CI/CD friendly...). They might not be ás technical as myself, but parallel to trying to fix cloudbuilder, I'm going to explore GitHub - Esri/arcgis-cookbook: Chef cookbooks for ArcGIS  which perhaps gives a bit more granular control in comparison to the cloudbuilder...

Anonymous User · Answer

Hi! Yeah, these are all filled out. As stated previously, the file works great on a vnet created by ourselves. As for the firewall: we're using the esri-provided images, deployed programmatically in our image. No firewall config aside what is in azure resources. Cloudbuilder previously did that right, also in our poc. I also feel however that per-process whitelisting might not be the way to go... Our CSP also stated they specifically wanted sites...

RachelSears · Answer

Hi Randall,

By inbound communication, I did mean internal communication, and/or communication between the remote system and the integration platform. In some secure environments, the firewall is used to restrict internal communication, so I should have specified that point. Hope this clears it up!