Windows script defines several vars then issues a CALL to WinBat wbt script. The wbt script does see the user defined environment vars. The wbt see's all the Windows level-environment vars but not the ones defined by the caller. This problem does not occur on Win7 hosts. The problem exists on all Win10, Server 2012 and later. If we issue a "set" stmt from the wrapper we see all the vars, but the wbt EnvironList.wbt does not see any of the wrapper vars.
We are a long time WB user/customer.
Why????
Thx
Please post a sample script that can be used to demonstrate the behavior, along with some step-by-step instructions regarding exactly how you're starting the script.
Also, the following would be helpful:
1) Indicate whether you are, in fact, running an uncompiled WBT script or have compiled it to an EXE.
2) Include information regarding the User Account Control settings for the Windows 7 system [where you indicate things work OK] and the Windows 10 / Windows Server 2012+ systems.
3) If you are executing the script as an uncompiled WBT and are launching it by double-clicking it in the Windows Explorer or via a shortcut link, what are the file associations on these systems in terms of which WIL Interpreter executable will be launched to process the script.
Problem: Open a cmd window. Create a var "set USER_NB=nb" , issue a "set" cmd to confirm the var, Next from the open cmd run "run_wbat.cmd d:\EnvironList.wbt" to display the values for all the env vars and USER_NB is not displayed, all the system environment vars are listed but not the one defined in the cmd window.
run_wbat.cmd issues a "CALL d:\EnvironList.wbt" to display a pop-up list of the vars, no USER_NB
Win User Account Control is set to "never" on all machines
First, it has nothing to do with "user" variables. The WIL "Environment" and 'EnvItemize" functions have no problem accessing user environment variables.
If you are using an admin account, when you start a command prompt it is started as a restricted admin. When you start up a WinBatch script with the .wbt extension, it is running as an elevated admin. And a full admin process will not inherit things like environment variables from a restricted process. I am not sure why you don't pass information using command line parameters but if you change the extension of your WinBatch file to .wbt_if, it will be able to inherit environment variables from the cmd.exe process.
Nothing has really changed here except that on Windows 10 UAC is almost always active. On Windows 7 you could disable UAC by turning off the elevation prompt. On Windows 10 disabling the prompt does not disable UAC. It just turns off the prompt.
If you have a local environment variable you are setting, you can try the SETX command in Windows 10.
Like
setx USER_NB nb
Then the run of the plain wbt file will see that, and the wbt_if will also of course.
Win10 - Setting the Registry Key EnableLUA to 0 solves the issue (default is On indicated by a value=1) without having to make any changes to our scripts or using a wbt_if suffix.
Using the Conntrol Panel UAC setting of NEVER only does part of the job, changing the EnableLUA=0 completes turning off UAC.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] EnableLUA=dword:0
Thanks.
Yes, that registry setting is well known and has been mentioned multiple times on this forum. However, besides being a potential security risk, it disables or restricts features of the operating system that many find useful.
UAC, when enabled, provides significant advantages in terms of mitigating the scope of damage caused by a malware infection. Turning it off blindly as a means of making a script function properly isn't a good thing.
Consider this scenario: If one of the Windows 10 systems on which UAC has been fully disabled is infected with malware while a user with administrator privileges/rights is logged on, the malware potentially has carte-blanche access to the entire network in terms of other Windows desktop & server systems that it affect in a negative manner by either infecting them with itself, or corrupting/encrypting data files on all of them.
In the real world, this is a real problem and it happens on a daily basis where ransomware types of malware are concerned. In most well-run Windows computer networks, having UAC enabled typically limits the scope of the ransomware infection to just the workstation on which the intrusion occurred, and only a single user's documents in their user profile and/or network home folder end up being affected.
While I try to avoid being a "security scold", at least on the surface this would appear to be a case of introducing a potential security risk and crippling parts of the OS to save typing a few characters and that seems foolhardy at best.