Configuring Logon Processor as a Logon Script

Introduction

To run LoginPI.Logon.exe (the Logon Processor) when a test user logs in, you need to configure it as a login process. For this:

1. Place the executable in a location where it can be accessed.

2. Configure it to run at login.

Each user account should be dedicated to a single installation of Login Enterprise. The Logon Script must point to the specific Appliance URL.

Although it is technically possible to create a system where an account selects which appliance to connect to at login, you cannot have two remote sessions to the same account at the same time. Even if an account can detect which appliance to use, multiple appliances cannot coordinate access to ensure only one connects at a time. Configuring multiple appliances to avoid overlap introduces unnecessary complexity. Make sure to use separate accounts for each appliance.

LoginPI.Logon.exe must run as a process in an interactive logon session. It cannot run as a service or any other non-interactive process. It requires a real desktop environment with a window and a window manager.

Logon Processor Location

The Logon Processor must be in a location that test users can access automatically, without requiring an additional interactive logon. Common locations include:

1. The NETLOGON share in your domain

2. A folder on a standard file server

3. A directory on the VDI image

Place the executable in a location accessible to all test users using the same path. Avoid storing it in individual users’ personal shares.

Using a common location makes it easier to assign a single logon process to all users, rather than maintaining separate processes for each user.

NETLOGON

Domains often include a network share for logon resources, usually configured as the NETLOGON share under the domain name. For example:

\\MyDomain.com\NETLOGON

This share is normally accessible to any user who has successfully authenticated to the domain, making it a simple location for the executable. Drag and drop LoginPI.Logon.exe to the NETLOGON share, and configure your logon script to point to:

\\MyDomain.com\NETLOGON\LoginPI.Logon.exe ... (where ... would be additional parameters, like the URL of the Login Enterprise Appliance)

You may need to access the domain controller to place LoginPI.Logon.exe in the NETLOGON folder. The folder is located at:

%SystemRoot%\SYSVOL\DomainName\Scripts

The folder is shared out under the name NETLOGON.

Standard File Server Folder

Create a share on your file server that is accessible to all test users. You can configure an Active Directory user group containing your test users and grant read access to the share or to a folder within an existing share. Ensure that the permissions do not require additional authentication.

Configure your logon script to point to the executable using the UNC path, for example:

\\MyDomain.com\Shares\TestUsers\LoginPI.Logon.exe ...

On the VDI Image

You can place LoginPI.Logon.exe in a directory on the boot image or an image layer if you are using layering technology. For example, create the folder:

C:\Program Files\LoginEnterprise\Logon Processor\

and place LoginPI.Logon.exe in that folder when building the image used for test desktops. Configure your logon script to point to:

C:\Program Files\LoginEnterprise\Logon Processor\LoginPI.Logon.exe ...

You can also use lifecycle automation to install LoginPI.Logon.exe automatically at boot or during a refresh.

Pros and Cons

Boot image

• Pros: Simple to deploy. No need to manage network resources, permissions, or routing.

• Cons: Harder to update. We provide a new LoginPI.Logon.exe with every appliance update. Although the system is designed to be backward-compatible, you should update the program whenever you update the appliance, just as you would upgrade all Launchers.

NETLOGON share

• Pros: Simple to use in a controlled environment.

• Cons: May require additional permissions. You might need another team to place the program and update it when necessary.

File server folder

• Pros: Easy to configure, as long as test users can access it. Updating is as simple as copying the new file in place.

• Cons: Requires network access to the file server.

Login VSI training resources generally recommend the NETLOGON share as the simplest option, since a training lab usually provides full control over the testing domain.

Configuring a Logon Script

Typically, you configure LoginPI.Logon.exe as a logon script for specific users.

Avoid configuring a machine-level logon script. It will run for all users and may log other test users out unexpectedly. This is especially important when running Login Enterprise on a shared VDI pool. Even on a closed testing system, avoid this practice.

You can configure a process to run at logon using one of the following methods:

• Domain GPO

• Domain user profile properties

• Local policy

• Startup folder in the Start Menu

• Registry

• Scheduled task

• Profile Manager

Domain GPO

You can configure a Group Policy Object (GPO) to run a script at logon. A full GPO tutorial is beyond the scope of this section. To configure a logon script:

1. Create a new GPO.

2. Configure the GPO to include a logon script that points to your LoginPI.Logon.exe, including any required parameters.

3. Apply the GPO to your test users or to a user group containing them.

For detailed instructions on assigning logon scripts, see the Microsoft documentation.

Domain User Profile

To assign a logon script to a user:

1. Open Active Directory Users and Groups for your domain.

2. In the console tree, select Users.

3. Double-click the user to whom you want to assign a logon script.

4. Click the Profile tab.

5. In the Logon script field, enter the full path and any parameters for the script, and then select OK.

6. Repeat these steps for each user.

Startup Folder

If you place a program or shortcut in the Startup folder, it will be executed when Explorer starts up. That is, an interactive session starts when a user logs in.

• Current user: C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

• All users: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

You can also open these folders using the Run dialog: enter shell:startup for the current user or shell:common startup for all users.

To configure a startup process:

1. Place a script, a shortcut to a script, or a shortcut to the Logon Processor (with the required command-line parameters) into the appropriate folder.

2. The current-user folder affects only the logged-in user.

3. The all-users folder applies to every user on the machine, which dedicates the machine to testing.

Registry

To define a startup script through the registry, create one of these keys. You can configure a startup script by creating one of the following keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run – Runs programs for all users.

• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run – Runs programs for the current user.

HKEY_CURRENT_USER applies only to the account you’re signed in with. You must configure the key for every user who needs the script.

To configure the startup script:

1. Under the appropriate Run key, create a new value of type REG_SZ.

2. Enter any name for the value.

3. Set the value data to the full command line of the program you want to run, including parameters and any quotation marks required if you were entering the command in a Command Prompt window.

Scheduled Task

You can use Task Scheduler, the Windows built-in tool, to create a task that runs when a user signs in.

1. Open Start > Administrative Tools > Task Scheduler.

2. In the tree, select Task Scheduler Library.

3. In the Actions pane, select Create Task.

4. In the Create Task dialog, configure the following tabs:

   • General: Enter a name for the task.

   • Triggers: Select New, then set Begin the task to At log on.

   • Actions: Select New, then select Browse to locate your script.

Profile Manager

If you use a Windows profile manager such as FSLogix, Ivanti, or Citrix Profile Manager, you may be able to configure it to run this program at startup in user sessions. For configuration steps, see your profile manager’s documentation.

Configuration Considerations

The Scheduled task, Registry, and Startup folder options require changes to the base image or a roaming profile that follows the user. Configure them per user, not per machine, to avoid committing the entire machine to testing. These methods are useful for lab testing, but not recommended for production.

We recommend using a domain Group Policy Object (GPO) instead of a domain user profile. A GPO is easier to modify and can be applied to all users immediately. If each user profile has a logon script, you must update every profile to make a change.

Avoid configurations directly on the VDI machine. They don’t apply in streamed app environments, where you may not control the local configuration of the app server. Domain-level policies follow the user, even to the app server.

Your profile manager may have the configuration flexibility you need to target specific test users or hosts. Because we don’t provide documentation for profile managers, check your product’s options.