Licensing ArcGIS Server in secure cloud subnet

[Anonymous User]

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...

[JoshuaBixby]

Instead of chasing the whitelist, which the CSP may not even allow in the end depending on the specifics, have your Esri license administrator look into doing "Secure Site Operations" in My Esri, which allows you to license a product that does not have access to Esri's licensing servers.

[RachelSears]

Hi Guus,

When you say the licensing file is correct, did you open the .prvc file itself in a text editor and verify that the "user information" parameters are filled out? When running the Software Authorization Utility programmatically (without the Wizard), these fields must already be filled out.

Regarding your firewall, you may need to add new inbound rules for the following applications:

• <ArcGIS Server installation location>\bin\ArcSOC.exe
• <ArcGIS Server installation location>\framework\etc\service\bin\ArcGISServer.exe
• <ArcGIS Server installation location>\framework\runtime\jre\bin\javaw.exe
• <ArcGIS Server installation location>\framework\runtime\jre\bin\rmid.exe

Hope this helps!

- Rachel

[RandallWilliams]

You don't need to open the firewall to access these processes to external traffic. In fact, I'd strongly recommend against it as those processes don't need to go outside of the network. While these processes are used by ArcGIS Enterprise, they're all used for internal machine communication, not external machine communication and don't pertain to licensing. 

https://service.esri.com and my.esri.com *should* be all you need to whitelist.I think this is an aynch request, so you should whitelist for both inbound and outbound communications. Basically you send the authorization info up, and the server responds with a separate file.

[RachelSears]

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!

[Anonymous User]

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]

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...