Any time I try to deploy a new site (with ArcGIS Enterprise Cloud Builder 10.8.1 for Microsoft Azure), I get the following error message:
Operation Failed. Error Details:
Could not find a part of the path 'C:\Users\tkennedy\AppData\Local\Temp\6c6bae7421d847348a6a51f97f24fac6\AGBaseproperties.json'.
The Temp\6c9bae7421d847348a6a51f97f24fac6 folder appears to get created with every deployment so I can't even pre-populate it with the appropriate json files. It appears to occur no matter what options I choose. Has anyone encountered this before?
Hey @ChristopherPawlyszyn - thanks for follow up. Yes absolutely - please see below and attached for deployment summary.
DNS Name:- arcgistestpip.centralus.cloudapp.azure.com
Create New:- Yes
Resource Group:- my-rg-name
Web GIS:- Yes
From Esri Image:- Yes
Image Name:- ArcGIS Enterprise 10.8.1
Total Machines:- 1
Machine Names:- hfWebGIS-Pri
Time Zone:- Eastern Standard Time
Enable OS Updates:- No
Remote Desktop:- No
ARM Resource Prefix:- hf
Deployment Storage Account:- mysaname (my-rg-name) (centralus)
Preserve artifacts:- Yes
Use Cloud Storage:- No
Uses Azure Monitor Logs Workspace:- No
Automatic VM Shutdown Enabled:- No
Machine Administrator UserName:- hellosir
Machine Administrator Password:- how!!Are84You
Portal Context:- portal
Portal License Path:- C:\Users\tim\azure\ArcGIS_Enterprise_Portal_1081_341609_20210209.json
Server Context:- server
Server License Path:- C:\Users\tim\azure\ArcGISGISServerAdvanced_ArcGISServer_1004840.prvc
Site Administrator UserName:- siteadmin
Site Administrator Password:- yesTo43Work
ArcGIS Service Account:- arcgis
ArcGIS Service Domain Account:- False
ArcGIS Service Password:- aHaHaH55
Azure Application Gateway Name:- hfAppGateway
Virtual Network Name:- arcgistestvn
Application Gateway Subnet:- arcgistestsnag
File Share Option:- On Single Machine
File Share Host:- hfWebGIS-Pri
Data Store Types:- Relational
SSL Option:- CA Issued Certificate
Key Vault:- mykv (centralus)
Key Vault Secret:- mykvsecret
Domain (Alias):- arcgis.mydomain.com
Pfx Password:- sse33%dg3$
Have you tried exporting the artifacts prior to hitting the final button to start the deployment? I'd be curious if the AGBaseproperties.json existed within those exported files. Nothing in your summary immediately jumps-out as causing an issue, so I'm thinking we may need to look further in the Azure logs.
If you login to the Azure portal in a browser, then select Monitor and Activity Logs, you should see a failed deployment with a drop-down arrow. Selecting the event that failed and looking at the JSON output should give you the clearest indication of anything Azure-size that the Cloud Builder application may not be aware of. I can drum-up a screenshot if it would be helpful as well.
I did at the time but didn't hold on to them. Cloud Builder worked when I changed the region from Central US to East US so I suspect it was related. I have been cleaning out the resource group after running things so no longer have the relevant outputs. I'll try to recreate the behaviour and figure out what the problem is with my new found troubleshooting knowledge. Thanks for your help :grinning_face:
It may be useful to capture the API requests during the site configuration using a tool like Fiddler, this will pinpoint where the failure is occurring in the configuration steps and also get the full message from the 400 response. Let me know if you need more explicit instructions on how to do so.
I had a similar issue, for me the issue was underlying in using an SSL certificate in the azure keyvault according to the fiddler logs (which I did not keep). I swapped to a self-signed certificate, and both the staging artefacts and the deployment would work rather than a "no path available" issue.
I had the same issue as the OP. After trying many of the tricks above, I found that when I finally created a new storage account within the same resource group, I was able to finally get CloudBuilder to fully install without errors. Upon reviewing the old storage logs, there were references back to the hard drive directory mentioned above with locks. This was mainly caused from installing a new version in the same resource group and reusing the storage account.