IntControl 59 Question

[LouInova]

Hi,

I've been trying to create a script that adds an environment variable for an RDS/Citrix application. The application is published in seamless mode.

I'm adding the variable to the HKCU\Volatile Environment\(session ID)\ location as it needs to change each time the user logs on since it is a variation of the CLIENTNAME variable (client computer name) the system creates at initial logon.

I've noticed that if I have a full desktop session open and I run the script, that it successfully adds the new registry entry and the variable is visible if running a Set command. However, if I run the same script in the seamless session (no desktop), it adds the registry entry but the variable is not visible when using the Set command.

Is there an issue with the IntControl function when there is no "top" window present? Is there another way to send the "change" command so that it successfully registers the new variable in the environment list? Am I overlooking something else that I should be accounting for?

WB Version = 2012B
OS = Srv 2008 R2
Failing Command = IntControl (59, -1, "Environment", 0, 0) and/or IntControl (59, -1, "Volatile Environment", 0, 0)

Thanks,
Lou

[Deana]

IntControl 59 merely sends a WM_SETTINGCHANGE message. Here is the documentation for that message: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725497(v=vs.85).aspx. Honestly I have no idea how the WM_SETTINGCHANGE message works in the context of a seamless session.

You mention that if you run the script in a seamless session the variable is not visible by the SET command. I am also not familiar with the Volatile Environment.

This might be helpful? http://us.generation-nt.com/answer/how-set-environment-variable-via-jscript-help-76674402.html

Anyone else?

[td]

There are some important details missing from the description of the problem but one thing is clear; it is not an 'issue' with IntControl 59 and no 'top window' being present. The cause lies within the Citrix session manger implementation and might be the result of the user using multiple sessions or some other facet of  the 'seemless mode' implementation.

[LouInova]

Sorry that it took me a while to get back to this.

Thank you for the replies. The link that Deana provided gave me a better understanding of what may be happening and I was able to adjust the script to make it work.

In essence, and to the best of my still limited understanding of how it all meshes together, when there is no full desktop, the VM_SETTINGCHANGE message was getting lost much as in the same manner if you use the SET command in one specific DOS window - it will only apply to that "environment" and not to another DOS instance since it is not a child process.

As described in the thread that was linked, explorer.exe has the ability to trap the change and it will be present for other spawned processes. However, in a seamless session, that's not the case since there is no underlying Explorer process (or anything that seems to be able to trap the windows change message and persist it). Hence, the spawned application must be made a child process in order to retain the environment change.

Given that, I used a combination of EnvironSet and RunEnviron instead of IntControl 59 and ShellExecute.

As an FYI: Seamless sessions in this case use DVM.exe (instead of Explorer) to track the session space (along with wfshell.exe). Not sure if this might be pertinent info for those that get more into the nuts-and-bolts of things to see if these processes could trap a WM_SETTINGSCHANGE message and/or if it's done differently than with Explorer.

Thanks again for your help on this,
Lou

[Deana]

Thank you for sharing your solution.

[td]

Sorry that it took me a while to get back to this.

Thank you for the replies. The link that Deana provided gave me a better understanding of what may be happening and I was able to adjust the script to make it work.

In essence, and to the best of my still limited understanding of how it all meshes together, when there is no full desktop, the VM_SETTINGCHANGE message was getting lost much as in the same manner if you use the SET command in one specific DOS window - it will only apply to that "environment" and not to another DOS instance since it is not a child process.

As described in the thread that was linked, explorer.exe has the ability to trap the change and it will be present for other spawned processes. However, in a seamless session, that's not the case since there is no underlying Explorer process (or anything that seems to be able to trap the windows change message and persist it). Hence, the spawned application must be made a child process in order to retain the environment change.

Given that, I used a combination of EnvironSet and RunEnviron instead of IntControl 59 and ShellExecute.

As an FYI: Seamless sessions in this case use DVM.exe (instead of Explorer) to track the session space (along with wfshell.exe). Not sure if this might be pertinent info for those that get more into the nuts-and-bolts of things to see if these processes could trap a WM_SETTINGSCHANGE message and/or if it's done differently than with Explorer.

Thanks again for your help on this,
Lou

Thanx for posting back. Always good to learn something new.  It is interesting that Windows relies on the shell to propagate the WM_SETTINGSCHANGE broadcast message instead of perhaps the kernel or some GUI system process.

[td]

The more I think about it, I suspect that the WM_SETTINGSCHANGE message is being blocked by the wfshell.exe process hosting your session (could be for security reasons).  This means that all GUI processes on the system are not given a chance to adjust their environments because they never receive the message.  Among those denied processes is the process responsible for spawning new processes when you call ShellExecute.  Since the process tasked with spawning processes does not have an updated environment, your spawned process does not get it either.  Using RunEnviron on the other hand, calls CreateProcess directly with parameters set to pass the callers environment on to the new child process.  Since the caller is the one that changed the environment it has the change and passes it along.  This is purely speculative but it does match the evidence as I understand it.