Configuring the Python Path for Script Execution

Problem

Running scripts and installing packages with pip requires write access to your local data folder. By default, Extender uses the %LOCALAPPDATA% environment variable. For most users, this requires no action.

You need to change the path if any of the following apply:

  • You run the application under IIS, using IUSR or ApplicationPoolIdentity.
  • You use Terminal Services and receive a different LOCALAPPDATA path on each login.
  • Your LOCALAPPDATA folder is deleted daily, or at login.
  • Your LOCALAPPDATA folder is located on a network drive.
  • You sometimes Run as Administrator and sometimes don't.
Note: If you sometimes Run as Administrator and sometimes don't, there is no configuration that resolves this. Each mode resolves LOCALAPPDATA differently, so the path will keep changing under you. Don't Run as Administrator. There is no supported reason to do so.

Default Setup

By default, the application reads %LOCALAPPDATA% to locate your local data folder. This variable is set per Windows user, so each user gets a separate, writable folder without any setup. A standard desktop session needs no configuration at all.

Note: Under IIS, ApplicationPoolIdentity creates a hidden Windows user, for example IIS AppPool\DefaultAppPool. For this user, LOCALAPPDATA points to: 
C:\WINDOWS\system32\config\systemprofile\AppData\Local
This account does not have write access to that folder. As a result, it can't check out scripts, can't run them, and can't install pip packages. You end up with errors opening screens or views
Tip: The LocalSystem account does have write access to this folder. If you set the Application Pool identity to LocalSystem instead of ApplicationPoolIdentity, scripts and pip installs work with no further changes. Refer to your application and IIS documentation for the steps to change an Application Pool identity.

Example: When using Sage CRM, AutoSimply Barcode, A/C Chat or TeamWork, you will encounter the issue if IIS authentication is configured to use IUSR or LocalSystem. While this is not common on production servers, it is more common with sample data on demo machines. We need to allow the user to specify where to check out the scripts so they can set folder permissions.

Options to Change the Path

If the default LOCALAPPDATA path doesn't work for your setup, you have two options: add a viconfig.ini file or update the registry. We suggest you use viconfig.ini for new configurations going forward.

Option 1: Registry

This is the existing method. You set a fixed path in the registry, and every user under that machine or identity uses it.

Changing Extender script path in the registry

Editing the registry requires regedit access. Many users don't have this, which is one reason viconfig.ini was introduced.

Option 2: viconfig.ini

Place a viconfig.ini file in the SharedData folder to set the path in a plain text file instead of the registry.

In viconfig.ini, you can set the path at any of these levels:

  • Machine
  • Company
  • Windows user
  • Sage user

This lets you, for example, set the path only for the SYSTEM (IIS) user, while every other user continues on the default LOCALAPPDATA behavior.

To configure the path with viconfig.ini:

  1. Open the SharedData folder.

  2. Create or edit the viconfig.ini file. Refer to the sample file provided for the correct Format.

  3. Add an entry for the scope you need: machine, company, Windows user, or Sage user.

  4. Enter the folder path for that scope.

  5. Save the file.

Note: Settings in viconfig.ini apply only to the scope you specify. Any user not covered by an entry continues to use the default LOCALAPPDATA path.

using VI.Config sample file

 

Tips:

There is a viconfig.ini.sample file in the VIXXA folder. You can copy it and rename it viconfig.ini.

 

; You can split into multiple files to make it easier.

#include "vi-{machine}.ini"

#include "vi-{company}.ini"

#include "vi-{winuser}.ini"

#include "vi-{user}.ini"

 

Recognizing a Path Permission Issue

If a user doesn't have write access to the configured path, pip installs and script checkouts fail. Look for these signs:

  • Scripts fail to check out or run under IIS, but work fine in a desktop session.

  • pip install commands fail silently or return a permissions error.

  • The failure is specific to one Windows user or identity, such as an Application Pool identity.

Note:

Extender (PU14.04 and above) displays an explicit error message when pip install commands fail.

Solution

To resolve a path permission issue, do one of the following:

  • Change the Application Pool identity in IIS to LocalSystem.
  • Add an entry to viconfig.ini for the affected user or machine scope.

Refer to Options to Change the Path above for the steps for each method.