Our organization generally views program execution outside of the C:\Program Files or C:\Program Files (x86) directories as malware attempts and blocks execution using Microsoft's AppLocker.
The ArcGIS Pro 1.1.1 software tries to check for update availability like this, even when the install directory was allowed to default to C:\Program Files\ArcGIS\Pro:
C:\USERS\TIM\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\{86DF19EB-4AD6-4306-8C1B-6F39E10EC2D9}\ARCGISUPDATE.EXE
So, via an Esri support case, I've requested consideration of this design as a bug. No final status on that yet.
The question -
Do other organizations view this behavior as a malware signature? Thoughts, comments, instructions are all welcome.
My objective is to find a way to allow ArcGIS Pro to check for update availability when a user starts it, given our AppLocker configuration.
thanks!
tim
Solved! Go to Solution.
Thought I'd better wrap this one up with the final findings. Many of the ArcGIS Pro executables were not digitally signed at version 1.1.1, including ArcGISUpdate.exe. AppLocker in our environment is configured to not run untrusted executables from specifically blacklisted locations, e.g. from C:\USERS\TIM\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\. Esri tech support opened a medium severity bug for this on 12/4/2015.
edit: example of blacklisted location.
At our institution (a university) hardware and software is configured to meet the requirements of the users. We have had no issues with anything security wise (or otherwise) when configured properly. I would be surprised if our user-driven model was not widely used by other organizations.
Oh, this makes me yearn for the days of learning, enlightenment, and user-driven models at university!
Things can be a bit different in centrally managed, firmly secured environments. The IT hardware and software resources here are configured to adhere to laws, align with administrative policies, and enable staff to perform their duties, which creates a narrower solution field hemmed in by more constraints.
Your point is well taken, and it presents an approach for which I advocate regularly.
Tim nice point... I wasn't suggesting our was better, just different. Sometimes, 10 people helping a person cross the road can create its own problems
Guys,
FWIW I posited the question to the dev group responsible for the updater infrastructure, and they're discussing possible changes for a future release to mitigate some of these issues. Thanks for bringing this up as a possible enhancement!
Thanks Jeremy! A quick update, and hopefully a resolution for our environment, anyway... During the course of working the support case, our team noticed that the ArcGISUpdate.exe file went from being unsigned to being signed. Our AppLocker policies allow the Esri-signed file to execute. So, the issue was resolved locally. Maybe there are other changes to consider for a more generic fix.
Hi, Jeremy,
I just installed the ArcGIS Pro 2.0 today. The issue is still there. The ArcGIS Pro software installed is in the white-list controlled environment. The publisher is not enabled.
Wonder whether Esri has plan to put this file in a specified location?
What impact will be if the file is blocked?
Thanks
Helen
Thought I'd better wrap this one up with the final findings. Many of the ArcGIS Pro executables were not digitally signed at version 1.1.1, including ArcGISUpdate.exe. AppLocker in our environment is configured to not run untrusted executables from specifically blacklisted locations, e.g. from C:\USERS\TIM\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\. Esri tech support opened a medium severity bug for this on 12/4/2015.
edit: example of blacklisted location.