Environment Variable inconsistency

GreenRaven · May 18, 2026

We utilize the ClientName variable in our production environment, but we've had some inconsistent results in it's behavior.

From what I understand, when using remoting technology such as RDP, windows creates a value in HKCU\Volatile Environment\<session ID> called 'CLIENTNAME' with the value being the remote device's computer name. Then, when software is launched, it reads from HKCU\Volatile Environment, HKCU\Environment, and HKLM\System\CurrentControlSet\Control\Session Manager\Environment.

Herein lies my dilemma. Occasionally, when our users log into their sessions (we utilize Omnissa Horizon VDI, using Horizon Blast) for the day, some of them (roughly 1-2%) will not have the Environment variable set for CLIENTNAME. This is validated by the 'set' command being ran in command prompt, with the results not showing the CLIENTNAME variable shown at all. When I check the registry, the value exists and is populated with the client device name. I then re-launch CMD and run the command again, to validate it is not a timing issue, and it still does not show.

Then I restart explorer.exe using task manager. Once I do this, and re-launch CMD again, it shows when I run the set command. I could see maybe explorer caches some variables and it's referenced from there, but that thought falls apart when I continue testing.

Once the variable is set and explorer is relaunched, I can make any changes to the registry key/value and it will reflect upon re-launching CMD, as expected.
There are other variables in HKCU\Volatile Environment\<session ID> that also do not populate until explorer.exe is restarted.

Is this a bug or am I misunderstanding how windows handles environment variables?

Thank you.

glasskuter · May 18, 2026

@pseymour is an IT guy. Maybe he knows.

pseymour · May 18, 2026

GreenRaven said:
Is this a bug or am I misunderstanding how windows handles environment variables?

Slight misunderstanding. This part isn't true...

GreenRaven said:
Then, when software is launched, it reads from HKCU\Volatile Environment, HKCU\Environment, and HKLM\System\CurrentControlSet\Control\Session Manager\Environment.

A process gets an environment block at creation time, and that block is usually inherited from the parent process. The registry locations you mention are primarily used to construct an initial environment block during logon/session initialization. After that, processes mostly inherit from already-running parent processes.

In your case, probably either explorer was started before the volatile environment variables were merged, or before Horizon finished populating everything.

Any process launched from explorer (cmd, Run dialog, shortcuts, etc.) would inherit explorer's process block. That's why the variable is present after you restart explorer.

As for why registry changes are reflected later, well it's possible cmd could re-query the volatile environment, or Windows or some APIs may do it, but I wouldn't rely on that. The initial shell process for the user's session is what matters the most.

But yeah it is frustrating.... we had to do stuff like this in my Citrix days...

Powershell:

    if (Test-RegistryValue -Path "Registry::HKLM\Software\Citrix\Roles\XenApp" -Name "Installed")
    {
        [string]$XenAppInstalled = (Get-ItemProperty -Path "Registry::HKLM\Software\Citrix\Roles\XenApp").Installed
        if ($XenAppInstalled -eq "1")
        { # XenApp is installed. Wait for the ClientName environment variable to be set.
            Write-Log "XenApp is installed."
            $maxSleepSeconds = 45
            Write-Log "Waiting for up to $($maxSleepSeconds) seconds for CLIENTNAME environment variable to populate."
            $clientName = [System.Environment]::GetEnvironmentVariable("CLIENTNAME", [System.EnvironmentVariableTarget]::User)
            while (([string]::IsNullOrEmpty($clientName)) -and ($maxSleepSeconds -gt 0))
            {
                Sleep -Seconds 1
                $maxSleepSeconds--
            }
            Write-Log "Finished waiting for CLIENTNAME environment variable to populate."
            Write-Log "CLIENTNAME variable = `"$clientName`""
        }
    }

GreenRaven · May 18, 2026

pseymour said:
A process gets an environment block at creation time, and that block is usually inherited from the parent process. The registry locations you mention are primarily used to construct an initial environment block during logon/session initialization. After that, processes mostly inherit from already-running parent processes.

This does make sense with the initial behavior, but why does it behave differently after explorer is re-launched? I'm asking so I can have a better idea of how windows works, since it's not adding up for me still.

Thank you @pseymour. I have a feeling I'm going to implement something similar to that script, I just have to figure out what layer will allow me to integrate it.

pseymour · May 18, 2026

That's what I was saying about maybe cmd refreshing some variables, or Windows, or some API... I don't know the internals of that, so anything I say would be a guess. I do know that the PowerShell code I posted reads the environment variable, not the registry, and it eventually gets the CLIENTNAME value, so it's possible for a given process to get an up-to-date environment variable at some point, but I wouldn't know what that is for any given process. Maybe in the case of Citrix XenApp back then, maybe it (XenApp) was forcing a broadcast message of some sort saying, "hey I updated the environment variables, everyone check back in!" I dunno.

There are other smart folks around; maybe someone knows.

Alejandro85 · May 19, 2026

Without knowing too much about your specific environment, but there is a chance that it happens because the users, when leaving the remote session, just close the remote desktop instead of logging off their session. It can also happen when you use the thing locally.

Just closing the remote window leaves everything running in the server, including explorer, any cmd window and all applications, each one retaining their respective environments. Since environment variables are populated at process start, you may be left with an older set (this is why everyone tells you to reboot when changing them). If you logoff instead of just closing, your programs are closed and when the next session starts you get a fresh set of environment variables.

Another way to tackle this is to forget entirely about environment variables (as you've seen how unreliable they are) and just use the Windows API directly to get this value. Have a look here for example:

Preferred way Of getting Client name From Terminal Server Session

I need to get the underlying client PC name from a user's terminal server session. I know it lives in HKEY_CURRENT_USER\Volatile Environment\CLIENTNAME but is there another (preferably native .net)

stackoverflow.com

GreenRaven · May 19, 2026

@Alejandro85, as much as I would love it, the software has to point at an environment variable. If it's not the native one, I would essentially have to capture the data and put it into an environment variable anyway.
The issue does not come from a stale session. As of right now there is a completely separate issue we're facing where any disconnect completely locks users out of their sessions (It's on the backburner and I haven't had a chance to look at it too closely yet)

I appreciate the info though. If it's more of a constant, I may do that process instead. I'll have to do some testing.

andrew129260 · May 19, 2026

I am no expert, but in terms of what I could find......Windows doesn’t reread the environment from the registry every time you start a program. Each process keeps its own copy of the environment it was given when it started, so if explorer has an old environment, apps launched from explorer will inherit that old copy.

When a process starts another process without a custom environment, the child gets a copy of the parent’s environment. From what I can find, Microsoft’s help pages say the new process uses the calling process environment. That means the environment is a snapshot, not a live view of the registry. So when you open explorer it will only show the environment explorer had at the time you launched it.

I would guess it is more likely a timing issue between horizon agent writing the info and explorer initializing. I know you said you ruled it out, but explorer might be too busy tripping over itself during log on for a second, or maybe you have some logon scripts or something delaying it, or maybe it is because win 11 has a mind of its own.

I would check the following:

Horizon agent and client versions, are they up to date? Maybe you have some on sportatic versions? Are you on current release (CR) or the extended service branch (ESB) ? I would imagine the extended service branch would be ideal for testing this.
Do you have any logon optimizations, scripts, GPOs etc that might start slow down explorer at login? Try disabling them as a test and see if things improve.

This might be helpful:

Knowledge Base

kb.omnissa.com

pseymour · May 19, 2026

The login script thing is something I thought about yesterday, but in the opposite way of what Andrew is thinking. Windows doesn't wait for logon scripts, by default, before loading the shell. There are GPOs to set it to wait, but the default is off. I can't recall their names, but it's something like "wait for logon scripts" and "wait for the network." I was wondering yesterday if you set those one or both of those policies to wait, if you would have more consistent results. Neither one has anything to do with environment variables, per se, but maybe the delay itself is what the doctor ordered.

garlin · May 19, 2026

A child process inherits the parent process's environment variables. Now if you're in an interactive shell session or running a script, that parent process can update its own variables.

But if your shell is File Explorer, then it doesn't have any way to update its environment. There isn't an API call for that. So you would have to kill Explorer, and hope the parent process in your session creates a new Explorer which inherits the variables you wanted. But if the parent process wasn't refreshed with CLIENTNAME, then you're in the same place as before.

andrew129260 · May 19, 2026

From that link to the knowledge base I posted previously I just noticed it did not fill in the title making it look like a generic link

In some versions of Win11 VDI, environment variables related to Horizon Client may not be retrieved immediately after logon. (6001139)

Anyway it states the following:

When a user connects to a vdi, Omnissa Horizon Client gathers information about the client system and the connection broker sends that information to the remote desktop.
Horizon Agent writes the client computer information to the system registry path HKCU\Volatile Environment on remote desktops that are deployed on single-user machines.
This value is stored as a VDI environment variable with the following format: ViewClient_***
For example, it can be referred to using the set command in the command prompt.
However, in some versions of Win11 VDI, environment variables related to Horizon Client may not be retrieved immediately after logon.
This may be occurred due to the time lag when retrieving that value after VDI logon.

The following workarounds are suggested.

After logon to a VDI, wait approximately 1–2 minutes before launching the command prompt for referring the value.
Use the reg query "HKCU\Volatile Environment" to retrieve values from the registry.
In the Command Prompt, open a new tab and reference the value there.

Environment Variable inconsistency

New member

My Computer

aka Mama Glass

My Computers

putting the mental back in experimental

My Computer

New member

My Computer

putting the mental back in experimental

My Computer

New member

My Computer

New member

My Computer

Well-known member

My Computers

putting the mental back in experimental

My Computer

Well-known member

My Computer

Well-known member

My Computers

Similar threads