Select to view content in your preferred language

ArcGIS Pro 3.2.2. Pro.settingsConfig Variables not working

467
2
Jump to solution
05-22-2024 10:40 PM
Labels (1)
JosephMcGehan
Occasional Contributor

We are a multinational with hundreds of users around the world. We use GPO to configure ArcGIS Pro. It creates folders, moves files, and manages the registry. Our IS&T uses roaming profiles aggressively, which is terrible for GIS Performance. So naturally we move our heavy temps like basemap caches back to a C drive location. The Pro.settingsConfig is a great concept for us. 

Pro.settingsConfig was working at ArcGIS Pro 3.0 and 3.1. It's not working for us at ArcGIS Pro 3.2.2. There are 76 variables, we configure 29, and most do not work or only half work. for example,

When the spellcheck variable is unlocked, and false, the application is unlocked but ticked (it should be unticked), when the spellcheck variable is locked, and false, the application is locked and unticked (as expected). 

A pattern has emerged, if the first variable is locked the second variable is honored. If the first variable is unlocked the second variable is mostly ignored. If there's a registry setting and its registry key is removed, then the Pro.settingsConfig starts working as designed for that variable. Unfortunately, not all of my 29 variables have registry keys to revoke to force the config to work. 

After removing all of the companies GPO and modifying my move config file to roaming registry setting to 0. I found no changes to the issue. 

I made a quick video of the issue for Esri Support. Esri Case #03617505 - Admin Settings Config XML not working for ArcGIS Pro.

A_config.pngB_config.pngC_config.png

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
JosephMcGehan
Occasional Contributor

We moved our ticket to Premium Support and discovered this was BUG-000164358. 

You will note in the bug documentation that Esri contradict themselves by claiming this BUG is a "designed" behavior, despite the fact that this "design" defeats the purpose of having a configuration file, which worked in the previous versions. Support recommends submitting an enhancement request. 

https://support.esri.BUG-000164358 

Joe

 

View solution in original post

0 Kudos
2 Replies
JosephMcGehan
Occasional Contributor

We moved our ticket to Premium Support and discovered this was BUG-000164358. 

You will note in the bug documentation that Esri contradict themselves by claiming this BUG is a "designed" behavior, despite the fact that this "design" defeats the purpose of having a configuration file, which worked in the previous versions. Support recommends submitting an enhancement request. 

https://support.esri.BUG-000164358 

Joe

 

0 Kudos
JakubPruchnik
New Contributor

Although solution is saying it is a bug based on my own experience with both Pro.settingsConfig and user.config position of settings in those config files matter. When config file is read during application start-up some settings need to be present in order to be properly applied. For example my recent example(however in file user.config) :

This will work:

<setting name="CreateNewDefaultFolder" serializeAs="String">
<value>False</value>
</setting>
<setting name="DefaultFolder" serializeAs="String">
<value>c:\temp</value>
</setting>

This will not work:
<setting name="DefaultFolder" serializeAs="String">
<value>c:\temp</value>
</setting>
<setting name="CreateNewDefaultFolder" serializeAs="String">
<value>False</value>
</setting>

0 Kudos