Latest Contributions by ArchitSrivastava

Hello @LavanyaVasudevanNES , Thanks for the additional details. That makes the setup much clearer. Since the current 10.9.1 production environment will not be touched, and the new 11.5 environment is completely separate, this sounds cleaner than trying to modify the existing production deployment directly. Also, since the Portal items, maps, layers, apps, and tools from gistest do not need to be preserved after the URL change, that removes some of the risk around item URL updates and content dependencies. In that case, your idea of using the test environment to validate the URL change workflow makes sense to me. The intermediate step: gistest -> gistest2 -> gis Could be useful as a rehearsal before the final go-live change. It would let you confirm the URL update sequence, federation behavior, IIS / hardening behavior, and license timing before moving to the final gis.domain.com URL. For the licensing part, I agree with your thinking. Provisioning a new license file for the final https://gis.domain.com/portal  URL sounds cleaner than trying to modify the temporary gistest license, especially since the new 11.5 environment will eventually become the production environment. The main thing I would still be careful about is treating the go-live step as a full Enterprise URL change, not just a Portal rename. Even if the content does not need to be preserved, I would still validate federation, Server URLs, WebContextURL, DNS/IIS routing, Portal licensing, ArcGIS Pro connections, and the geodata service after the URL change. Some IT / cutover items I would also keep in mind separately are: DNS cutover timing from gistest.domain.com to gis.domain.com Lowering DNS TTL before the cutover window, if your IT team allows it Confirming the final DNS record points to the correct load balancer, reverse proxy, or IIS/Web Adaptor endpoint IIS bindings for the final hostname Web Adaptor URLs and routing after the final hostname is active Firewall/security group rules for the new 11.5 machines Load balancer health checks, if one is used Certificate coverage for the final gis.domain.com hostname Confirming old gistest references are no longer used after go-live Checking whether any internal scripts, scheduled tasks, integrations, or asset management workflows have hardcoded URLs Confirming monitoring/logging is watching the new 11.5 environment after cutover Having a rollback or fallback plan documented, even if the old 10.9.1 environment is not being modified For your environment, the most important validation after the URL change would probably be: Portal and Server federation validation ArcGIS Pro connection and publishing Geodata service access Traditional versioned editing Two-way replica creation and synchronization Asset management system edits flowing back correctly IIS and Esri hardening rules after the final URL is in place Portal and Server logs after the change So I do not know of a much quicker supported shortcut, but based on what you described, your plan sounds reasonable: Test everything under gistest, rehearse the URL update if needed, generate a fresh license for the final gis.domain.com URL, and then do the documented URL update process at go-live. Hope it helps! ... View more

Hello @LavanyaVasudevanNES  I have not done this exact 10.9.1 to 11.5 side-by-side URL swap recently, but a few things stand out from the 11.5 documentation. First, I would be very careful with the Update organization URL workflow at 11.5. The documentation currently has a caution that this workflow is impacted by a defect and requires a patch before proceeding: Update the organization URL—Portal for ArcGIS | Documentation for ArcGIS Enterprise So I would definitely confirm that patch is installed before testing this workflow. The second thing is that this does not look like a simple Portal URL change only. From the documentation, the workflow updates URLs across the Enterprise organization, including: Portal URL / organization URL Portal Administrator Directory Portal items, maps, layers, apps, and tools each federated ArcGIS Server URL services, Server Manager, Server Administrator Directory, and Services Directory So if you go from: https://gistest.company.com/portal to: https://gis.company.com/portal I would expect the federated Server URLs to need the same careful handling as well, not just Portal. A few things I would check or plan for before doing the swap: Install the required 11.5 patch mentioned in the documentation Create a full WebGIS DR backup before making the change Make sure all federated servers validate correctly before starting Generate and save the URL reports before updating anything Update federated server URLs first, then update the Portal URL, following the documented order Confirm WebContextURL is set correctly for Portal and each federated Server before the change Update reverse proxy / load balancer / DNS / Web Adaptor routing as needed Confirm certificates include the final production hostname Check whether SAML/OIDC redirect URLs or metadata need updates Plan for ArcGIS Pro users to update their portal connection after the URL change Plan for a new Portal license file for the final organization URL after the change For the licensing part, I would be cautious about deleting or regenerating anything tied to the current production environment in My Esri. Since this is a temporary side-by-side environment that will later take the production URL, I would probably confirm the safest licensing approach with Esri Licensing or Support before changing the production portal license allocation. My understanding is that one possible path is to license the isolated test environment with the temporary URL, validate the workflows, then at cutover follow the organization URL update workflow and import the correct license file for the final URL. But because this involves the production organization URL and licensing, I would want Esri to confirm the exact sequence. After the URL change, I would test more than just whether Portal opens. I would check: Portal sign-in Federation validation Hosted feature layer access Referenced services Publishing from ArcGIS Pro Experience Builder apps Web maps and dashboards Traditional versioning workflows Two-way replication workflows Item thumbnails and attachments Server Manager and Server Admin URLs Portal logs and Server logs ArcGIS Pro portal connection and licensing behavior So I think the workflow is possible based on the documentation, but I would treat it as a full Enterprise URL migration, not just a Portal setting change. The 11.5 patch requirement, federated server URL order, WebContextURL, certificates, licensing, and app/service validation would be the main areas I would be careful with. ... View more

Hello @AYUSHYADAV , Thanks for sharing the details and the Portal log screenshot. The log message seems important here: Invalid_SAMLResponse: Unable to login using Idp. Error validating encrypted Assertion Unable to decrypt without a KEK The lower log entry also says: Exception in signIn using saml Unable to login using Idp. Error validating encrypted Assertion Unable to decrypt without a KEK Since DR SAML login works when Encrypted Assertions is turned off, it looks like the general SAML flow is likely working. The Entity ID, ACS URL, metadata, and basic Entra configuration may be okay. The failure seems to happen specifically when Portal needs to decrypt the encrypted assertion. Looking at the steps you followed, the part I would focus on is this: You imported the Production samlcert into DR using Import Root or Intermediate. From my understanding, that option is meant for importing root or intermediate CA certificates. It would not normally be the path used to make the DR Portal use the samlcert as the active SAML encryption/decryption certificate. For this specific DR SAML scenario, I would follow Esri’s geographic redundancy documentation closely: Disaster recovery and replication | ArcGIS Enterprise on Windows and Linux documentation In the Organization-specific login considerations for geographic redundancy section, Esri lists this SAML workflow: Export samlcert from the Production portaladmin endpoint. Delete the existing samlcert from the standby/DR portal. Use Import Signed Certificate to import the exported certificate into the standby/DR portal. Configure SAML in the standby environment. So I would try that documented path rather than importing the certificate as Root or Intermediate. For the private key side, this Esri documentation may also help: Import a certificate into the portal | ArcGIS Enterprise on Windows and Linux documentation That page notes that when importing an existing server certificate, the certificate and its associated private key must be stored in PKCS#12 format, such as .p12 or .pfx. That also explains why Import Existing Server Certificate asks for a password. This Esri Support article for encrypted assertions with Microsoft Entra ID may also be useful for comparing the Entra token encryption side: Create a Certificate and Enable SAML Encrypted Assertions with ArcGIS and Microsoft Entra Since you mentioned that you do not have access to the Azure Entra ID sign-in logs, it may be worth checking this with your Entra ID admin as well. They can help confirm whether Entra is issuing the SAML response successfully, whether encrypted assertions are enabled against the correct Enterprise application, and whether the certificate being used for token/assertion encryption matches what the DR Portal is expecting. So I think the next thing to verify is not only whether samlcert is visible on the DR Portal machines, but whether it was imported using the correct DR workflow and whether Portal has access to the key material required to decrypt encrypted assertions. The log message Unable to decrypt without a KEK seems to point strongly in that direction. Hope it helps! ... View more

Hello @AYUSHYADAV , Since Production is working and DR only fails after enabling Encrypted Assertions, I would probably focus first on the SAML encryption certificate side rather than the general SAML setup. A few things I would check: Does SAML login work in DR when Encrypted Assertions is turned off? When the SAML certificate was exported from Production and imported into DR, was the private key included as part of that import? In the DR HA setup, is the same SAML certificate available on both Portal machines? If you download the SAML metadata from both Production and DR, do the encryption certificate, Entity ID, and Assertion Consumer Service URL look the same? In Azure Entra ID, is token/assertion encryption using the certificate that matches what DR has? Are the Identifier / Entity ID and Reply URL / ACS URL in Entra ID still correct for the failover scenario? After importing the certificate into DR, was the SAML configuration saved or refreshed again in the DR portal? Do the Portal logs show anything related to decryption, certificate mismatch, or private key issues? Do the Entra ID sign-in logs show the SAML response being issued successfully, or does the failure happen before it comes back to Portal? My thinking is that encrypted assertions depend on Entra ID encrypting the assertion with the public certificate, and Portal then needing the matching private key to decrypt it. So even if Prod and DR look identical from the outside, a missing private key or a certificate mismatch in DR could cause this kind of issue. I would start by comparing the Production and DR SAML metadata side by side, especially the encryption certificate section, Entity ID, and ACS URL. If those look correct, then I would check whether the DR Portal actually has the matching private key available for decryption. ... View more

Hi @PaulCreaner1, No problem at all, and yes, please feel free to forward the questions to your ICT team. I understand. Since they were the ones who saw the login behavior directly, they may be able to confirm whether Field Maps was still pointed to the internal Enterprise portal or if it had switched to an ArcGIS Online/public sign-in flow. Please let me know what your ICT team finds when they get a chance to review it. ... View more

Hello @MargaretCrawford  Thanks for following up on this. From my workflow, I would expect the Calculate Field toolbar to remain open across attribute tables once it has been enabled, rather than being tied only to the specific table where I last used it. I do work with multiple attribute tables, but usually not all of them at the exact same time. More often, I move from one table to another while reviewing, comparing, reconciling, or updating attributes across different layers or tables. So in that case, if I enable the Calculate Field toolbar once, it would be helpful if it stays available when I open another attribute table, instead of needing to click Calculate again each time. For multiple tables open at the same time, I would expect the toolbar to be available for the active table view. I do not think it needs to preserve the exact field, expression, or calculation settings across tables. The main thing I am looking for is the toolbar visibility/state to persist, so repeated field calculation workflows feel smoother across tables. Hope that helps clarify the use case. ... View more

Hi @PaulCreaner1 , Just to understand the situation a bit better, can you share a few more details? Was the login screen shown inside the Field Maps mobile app, or did it open in a browser window? Before that screen appeared, was Field Maps connected to your internal ArcGIS Enterprise portal URL, or could it have switched to the default ArcGIS Online sign-in screen? Was the Enterprise portal URL manually added in Field Maps under the portal settings? When the Facebook or other social media login options appeared, did the page show your Enterprise organization name/logo, or did it look like a generic ArcGIS Online / ArcGIS account sign-in page? Are users normally signing in with built-in Portal accounts, enterprise logins such as SAML/ADFS/LDAP/OIDC, or another identity provider? Is the mobile device connected through VPN or the internal network when accessing Field Maps? Does that VPN restrict internet access to internal resources only, or does the device still have full internet access while connected? Is the device iOS or Android? Is the device managed through MDM? Do you know the exact ArcGIS Enterprise version? You mentioned 10.8, but it would help to confirm whether it is 10.8 or 10.8.1. What version of Field Maps is installed on the mobile device? Was ICT actually able to authenticate using a social media account, or did they only reach a screen where those options were displayed? These details will help determine whether Field Maps was still connecting to your internal ArcGIS Enterprise portal, or if it may have instead redirected to an ArcGIS Online or public ArcGIS sign-in page. ... View more

Thank you @DanPatterson  and @Robert_LeClair  That confirms what I was seeing. It looks like the Calculate Field toolbar is available when needed, but there is currently no setting to keep it open permanently or automatically reopen it after closing and reopening the attribute table. The floating table workaround is helpful to know. If the table is floated and minimized instead of closed, the toolbar can stay available, but once the table is closed and opened again, it resets. Thanks a lot for guiding me on this. I was trying to figure it out for a few days now. Based on the suggestions here, I went ahead and created an ArcGIS Pro Idea for this functionality: https://community.esri.com/t5/arcgis-pro-ideas/allow-calculate-field-toolbar-to-remain-open-in/idi-p/1717479 Feel free to let me know if I missed any important information that should be included in the idea details. ... View more

Hi @MohamedIsmailIssaMohamed, @George_Thompson , @Pam-Pritchett , and @DerekLaw already shared some great resources. I would just add that ArcGIS Enterprise is easier to learn if you approach it in layers instead of trying to understand everything at once. There are a lot of components, and it can feel overwhelming at first, but the pieces start making more sense once you understand how they work together. A learning path that I would suggest is: Start with the big picture Begin by understanding what ArcGIS Enterprise is and how the main components fit together: Portal for ArcGIS ArcGIS Server ArcGIS Data Store ArcGIS Web Adaptor The base deployment documentation is a good starting point: Base ArcGIS Enterprise deployment | ArcGIS Enterprise on Windows and Linux documentation Learn the base deployment first Before going into high availability, multiple server roles, Kubernetes, Notebook Server, Image Server, or other advanced topics, I would first focus on a standard base deployment. ArcGIS Enterprise Builder can also be useful for learning what a base deployment includes: ArcGIS Enterprise Builder | ArcGIS Enterprise on Windows and Linux documentation Understand what each component does Once the base deployment makes sense, I would look at each component separately: Portal for ArcGIS: users, groups, items, sharing, licensing, and content management ArcGIS Server: services, publishing, logs, directories, and service settings ArcGIS Data Store: hosted feature layers, relational data store, tile cache data store, and backups Web Adaptor: URLs, access, and how requests are routed to Portal and Server For Web Adaptor basics: Introduction to ArcGIS Web Adaptor | ArcGIS Enterprise on Windows and Linux documentation Practice publishing content This is where Enterprise starts to become more understandable. Try simple publishing workflows from ArcGIS Pro and then look at what gets created in Portal and Server. For example: Publish a hosted feature layer Publish a referenced map image layer Create a web map Create a dashboard or app Test sharing with users and groups Compare hosted data and referenced data This helps connect the admin side with the user side. Learn administration and security After that, I would move into administration topics such as: Users and roles Groups Sharing settings Licenses HTTPS and certificates Identity stores such as Active Directory, LDAP, or SAML Logs and troubleshooting Managing items: Manage items | ArcGIS Enterprise on Windows and Linux documentation Adding members: Add members to your portal | ArcGIS Enterprise on Windows and Linux documentation Learn backup, restore, and upgrades early I would not leave backup and recovery until the end. Even in a learning environment, it is helpful to understand WebGISDR and what it does. Backup and restore overview: ArcGIS Enterprise backups | ArcGIS Enterprise on Windows and Linux documentation Then move into architecture and scaling (when you are ready) Once you are comfortable with the base deployment and administration basics, then I would move into system design topics such as: Single-machine vs multi-machine deployments High availability Load balancing Separate server roles Cloud deployments Storage planning Performance monitoring Upgrade planning The ArcGIS Architecture Center is useful for this stage: ArcGIS system patterns | ArcGIS Architecture Center So my suggestion would be: Start with the base deployment, publishing workflows, users, groups, and backups. Then move into security, certificates, Web Adaptors, logs, performance, high availability, and automation. ArcGIS Enterprise feels complicated at first because it is not just one application. It is a platform made of several connected components. Learning it step by step makes it much easier. Hope this helps. I know this is a bit long, but ArcGIS Enterprise has a lot of moving parts, so I thought a step-by-step path might be useful. ... View more

Hello @MikaelJ , I agree with @GlenterpriseUK point about the SSM session context is where I would start as well. Since the same script works when you run it from RDP, or when you create the site through the browser, it feels like the issue may be less about createsite.bat itself and more about how the command is being run through SSM. A few things I would check: What account the SSM command is actually running under, likely NT AUTHORITY\SYSTEM Whether that account has the permissions you expect Whether you are calling createsite.bat using the full path Whether the script sets the working directory before running createsite.bat Whether the config store and server directories paths already exist Whether the account running the command can create or write to those folders Whether any path uses a mapped drive, since those usually do not exist in a non-interactive SSM session Whether passwords or special characters are being handled differently when passed through SSM/PowerShell Whether stdout, stderr, and the exit code are being written to a log file I would also try using a createsite.properties file instead of passing everything directly in the SSM command. That might make the test cleaner and avoid some quoting or escaping issues, especially with passwords and folder paths. For example: Set-Location "C:\Program Files\ArcGIS\Server\tools\createsite" .\createsite.bat -f "C:\Temp\createsite.properties" *> "C:\Temp\createsite_ssm.log" If the same properties file works from RDP but fails through SSM, that would help narrow it down to the SSM execution context, permissions, working directory, or folder access, rather than the site creation parameters themselves. Hope it helps!   ... View more

Hello @danbecker . I have not done this exact migration in Azure recently, but based on the Enterprise documentation, your approach looks generally aligned with the workflow Esri describes for changing the Portal content directory to a cloud store. A few things I would be careful about: The "objectStore" value should point to the Azure Blob container that will be used for the Portal content directory. In your case, the format seems to be along these lines: { "type": "cloudStore", "provider": "Azure", "connectionString": { "accountName": "saexample", "accountEndpoint": "blob.core.usgovcloudapi.net", "accountKey": "<key>", "credentialType": "accessKey" }, "objectStore": "https://saexample.blob.core.usgovcloudapi.net/portalcontainer" } I would only move the Portal content directory using this approach. The other Portal directories, such as db, index, and temp, should remain local to the Portal machine. For the private endpoint question, I would expect this to work as long as the Portal VM can resolve and reach the Blob endpoint privately, and the storage firewall, private endpoint, and private DNS configuration are all set correctly. I would pay close attention to: DNS resolution for the storage account Outbound access from the Portal VM Storage firewall rules Private endpoint configuration Private DNS zone configuration Whether the endpoint in the JSON matches the Azure cloud environment you are using, especially since your example uses the US Gov endpoint Before making the change, I would still take a full WebGIS DR backup and test the workflow in a lower environment if possible. For validation, I would split the checks into before and after the move. Before changing the Portal content directory, I would check: The Portal VM can resolve the storage account endpoint through DNS If using a private endpoint, the storage account resolves to the private IP The Portal VM can reach the Blob endpoint over HTTPS The storage firewall allows access from the Portal VM or subnet The access key or credential being used is valid The Blob container exists The objectStore path points to the correct Blob container There are no proxy, firewall, or Network Security Group (NSG) rules blocking outbound communication The endpoint matches the correct Azure cloud environment, especially for US Gov cloud A full WebGIS DR backup is available before making the change After changing the Portal content directory, I would check: Portal starts normally Portal logs do not show content directory or cloud store access errors Existing item thumbnails load correctly Uploaded files and documents open and download correctly Hosted layer item pages open as expected Attachments still open from existing items or layers StoryMaps, dashboards, and Experience Builder apps load correctly Map packages, layer packages, and other downloadable items still download correctly New item uploads work New hosted layer publishing works Editing or adding attachments to a hosted feature layer works Portal is reading from and writing to the new Blob-based content directory as expected The main thing I would validate is not just whether Portal starts after the change, but whether existing content, new uploads, downloads, thumbnails, attachments, and application dependencies continue to work normally afterward. Hope it helps! ... View more