In Pro 2.2, one has the ability to set indexing to run even when not signed into the computer, which is pretty handy, as you can set to run every night and completely reindex everything, which gives you a very small (5%) performance increase. Very easy, just type in your account password, hit OK, you can leave work with confidence knowing that Pro will be faster tomorrow because when you hit OK, there was no error message. Everything worked perfectly......
With one major caveat. Based on ESRI responses in other GN posts, the assumption is that every Pro user has complete administrative privileges over their workstation. The opposite is reality. The trend in most organizations is Zero Trust and Least Privileged Access. The typical GIS user does not have any sort of admin access to their workstation, and IT has do all of the installation and config changes, or they have at least automated the install (SCCM). So how does that relate to our Indexing situation?
The standard M$ Workstation STIG, which most organizations roll into their Group Policy, is to deny right to log on as batch job and right to log on as service. Exemptions typically include an AD group that only the central IT folks have access to, e.g a service that updates Antivirus or updates the GPO policy. Very few, if any, GIS folks are going to be in that exemption group.
So what happens when you check Update even if you are signed out of the computer is a Scheduled Task is created, but fails, as the user attempting to create the task does not have permissions to create a scheduled task. This can be confirmed by editing the task that is created when you check Update Only When you are signed into the computer and change it to "Run when logged out". The problem is that Pro didn't report this task creation failure, and the user now thinks that indexing is going to run successfully every hour or every night when not logged in. In reality, indexing is now never running.
In rare instances, setting the same indexing option (run when logged off) will not report failure when you set it while not logged into the network. Pro will not report failure, even though you can't schedule a task to run as a domain user when not logged into the domain. I tested this in an account configuration that is in the exemption group (which takes me two hours to login to).
This idea isn't about making some change to Pro that will allow indexing to run when not logged on when the user does not have permission to create scheduled tasks. That's not possible, as few IT folks are going to put dozens, hundreds, or thousands of users in a GPO exemption group that exposes incredible security risks. Using a local or System account won't work either, as many things that Pro indexes are access controlled by AD (e.g SDE connections) and again, IT is not going to be giving local computer accounts access to network shares and SDE databases. I considered using a service account, but again, that involves GPO exemptions and visiting every computer to set it up, and currently GPO only allows service accounts NOT in an exemption group to run tasks on servers, not workstations. Getting a service account added to a workstation GPO literally would require an Act of Congress.
Two things together (not separately, or just one)will make this idea "Implemented":
I know this is really Mickey Mouse but I know I'm going to have a ton of users checking that option, then 2 months later complaining about how slow Pro is, and I'll be on the phone with TS for hours trying to figure out why. I'm fine with just allowing indexing to run when logged in, I agree with the IT folks, no one in their right mind should grant everyone access to a security-risk setting.
A third, hopeful but unlikely outcome of this idea is the ESRI consider how Pro is deployed in most organizations security posture,and adjust accordingly. I can assure you, the IT folks pay attention to stuff like this when they consider what software will be allowed on the network. Software that requires more work on their behalf (e.g require only IT folks, the only folks with admin rights to install service packs 4 times per yer) is going to become less and less popular. I'm toying with the idea of allowing per user installation of Pro, which mitigates some of these issues, but that raises more problems when 10 users try that on the same workstation that has a 500 GB drive (remember, each installation of Pro requires 32 GB of free space!), and I'm pretty sure IT's not going to allow it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.