Windows Server 2016 can't read new environment variable - windows

I'm having a strange problem when installing my application on Windows Server 2016. (it runs fine on Server 2012 and Windows 7 to 10 clients).
FYI: I'm a software tester, not the programmer who wrote the code for the app or the installer. We deploy the app as .msi files, if that's important.
The installer for my application does three things:
- it installs all neccessary files, by default into the folder C:\myapp.
- it creates a directory C:\mydir\subdir and in that subdir it creates a file called info.text
- it sets an environment variable called myvar with the content C:\mydir\subdir\info.text
(it can also create a desktop icon to launch the app, but that icon is not important)
The content of info.text is simple plain text: a path where the program can find its database. By default it would contain the path C:\myapp\dbsubdir
This works really well for some decades now and also works fine when installed on Windows 10.
On Windows Server 2016 I run the installer and manually check if C:\mydir\subdir\info.text and the variable myvar are present - and they are. The file info.text also contains the right content.
Then I start the app by clicking the desktop icon and get an error message. I asked my software developer and he said this error message can only be caused by one of two things:
- the app can't find the environment variable myvar
- the app can't find the file C:\mydir\subdir\info.text
After I restart Windows the app starts as if the error had never happened.
On all other Windows Systems I can start the app directly after the installation is completed - my app doesn't require a restart of Windows.
I'm guessing that Windows Server 2016 needs a restart of some kind to be able to read newly created environment variables. But I found no proof for that thought or ideas how to get around that restart.
Is my guess true?
And if yes, is there a way around that restart?

Yes, I've seen this specifically with Windows Server 2016. The restart workaround is to logout and log back in. That seems to force re-read of your environment variables set.

Related

Inno setup scripting error [duplicate]

I am developing desktop database application. Using rdlc report and reportviewer. Everything was fine in developing process, reportviewer was showing all data smoothly. I deploy app with Inno Setup. But when I install the app, the reportviewer is not showing data. While data is correctly inserted in the tables.
For applications that work incorrectly or fail completely, when installed by Inno Setup to Program Files folder, the first thing to test, is to try to deploy the application manually to the same folder.
If the application fails even after a manual deployment, the most usual problem is that the application requires a user to have write permissions to application folder. As on modern versions of Windows a user typically does not have write permissions to the Program Files folder, the application does not work. So the problem usually has nothing to do with Inno Setup, but it's a problem of the application itself.
To solve the problem:
The best solution is to redesign the application so that it does not require write permissions to its folder. Windows applications should not require write permissions to their folder. That's against Windows guidelines. The application should write data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).
A dirty workaround is have the installer grant a user(s) write permissions to the installation folder. Do that only, if you cannot get the application fixed (e.g. it's 3rd party application).
See Inno Setup - How to set permissions of installation folder.
Even more gross workaround is to configure the application to be executed with elevated (Administrator) privileges.
See Inno Setup desktop shortcut (link) which has "Run as administrator" advanced property set
or How to set 'Run as administrator' on a file using Inno Setup.
Another solution is enabling legacy compatibility mode that makes Windows redirect all application write attempts to a virtual store. See also Application installed with Inno Setup writes files to unknown location instead of its installation folder.
There are numerous other possible reasons, why the application might be failing when installed, including:
You omitted some dependency:
DLL library
.NET assembly
.NET Framework
Java Runtime Environment
other runtime
COM/ActiveX object, etc.
The application requires some configuration:
a file
a registry key [including COM/ActiveX object registration]
an environment variable, etc.
The application is not designed to be executed from a folder that has a space in its name (Program Files).
The application gets confused by Windows File virtualization (though it's unlikely). See Application installed with Inno Setup writes files to unknown location instead of its installation folder.

WDS ImageUnattend does not run

We've successfully set-up WDS (Windows Deployment Services) and had it all working (it's serving an unattended Windows 7 x64 installation, the user only has to F12 then wait for the install to finish) but it no longer works the way it did before.
We're trying to F12 the exact same machine where it used to work. The WDS part of the installation is still automatic (unattended) but ImageUnattend.xml does not seem to run on the client at all now, it gets stuck at the language selection (everything after that is manual as well which is supposed to be automatic).
Inspecting C:\windows\panther on the client machine shows that WDS pops up with an error: WDS CallBack_WdsClient_CopyPrivatesDone: Failed to process client unattend variables.
Changing "%MACHINENAME%" to "*" in the ImageUnattend.xml file makes it all automatic again, however it then renames the computer incorrectly.
The variable %MACHINENAME% worked before, so why does it not work now? Has anyone else met this issue before?
Using a different user (domain administrator) in the ImageUnattend.xml file does not seem to change anything.
After countless of attempts with at least 15 new ImageUnattend.xml files, I decided to restart the server and use the original files I knew worked before.
This fixed it.

SQL CE 3.5 app won't work without Windows LUA elevation

I have a very simple CRUD app that uses SQL Server Compact (version 3.5) I want to deploy through private deployment vs. the click once installers. I have my installer created and everything works fine, minus one hiccup. The app won't work without Windows LUA elevation (Right clicking and selecting "Run as administrator").
The root cause of this, and this is my guess, is that my sdf data base is sitting inside the Program Files Directory. I think I remember reading somewhere, some time ago, that this directory was read only by default with LUA. Am I remembering correctly?
Also, any work-arounds to this that you've run across? I thought about throwing the sdf in the User's directory, but if another User logs on to the computer, they will not be able to access databases.
Your best bet is to place the file in %ProgramData% - create a folder there, and set the proper ACL via a script. I have some suggestion for manipulating DataDirectory here: http://erikej.blogspot.com/2011/02/using-sql-server-compact-40-with.html (also applies to 3.5)

WiX 3.0 throws error 217, while being executed by continuous integration

This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job

Visual Studio 2005 Setup project install crashes over Terminal Server

I have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!

Resources