How do I install another agent on the same Windows VM? I ran the MSI and installed it into another folder but it just unregistered the old one and the latest one took over.
What you've done so far is good, but its not the full story. For some God-forsaken reason, JetBrains made this super common thing, hard.
So you've one agent in D:\Agent-A and another in D:\Agent-B and during install you ensured they don't share any folders or ports etc.
Okay, now you have to open Notepad.exe as Administrator (to bypass the world's most annoying software 'feature', UAC) and edit:
D:\Agent-B\launcher\conf\wrapper.conf and near the bottom, append " B" to all the wrapper.console.title and wrapper.ntservice.* property values.
Now, open a Command Prompt as Administrator (to bypass the world's most annoying software 'feature', UAC) and CD into the following folder:
D:\Agent-B\bin
Now run:
service.install.bat
Check the outcome. Check that the new service appears in Windows. Start it. Wait for it to come online and authorize it in TC web UI if needed.
Done.
Related
If not mistaken,the error occured after I misclick a notification of a antivirus software that request for a permission.My computer is using Windows 10.May I know how to solve this problem?
Older answers on this software installation:
Node.js - Cannot Install it is showing an error because of .msi
Node.js install fails on Windows 10 1803
Blocking: This sort of problem can definitely be caused by an anti-virus software blocking access to the MSI in question. Disable the anti-virus temporarily and try again. If unable to do so, perhaps try to install on a virtual machine? (for testing or real use).
Windows Installer: Just to get it out of the way: I see some recommendations to re-register the Windows Installer components, but I prefer to eliminate other causes first (a broken Windows Installer usually indicates more serious system-wide problems - such as malware infection, or full disk or something else very fundamental).
Virustotal.com: Before temporarily disabling your anti-virus (the procedure for this is obviously different for each vendor), you should verify the actual binary or MSI using the virus checker interactively and also upload the file to https://www.virustotal.com/ to make sure the MSI isn't actually infected - if it is your anti-virus is doing its job.
Re-Download: It is also a good idea to re-download the MSI from the vendor site in case it has gotten corrupted during download. This happens very frequently. I have seen days wasted with corrupted installation media the unexpected cause. Virus test this new download too using https://www.virustotal.com/ (you want to check both old and new binary for malware - the file available for download can be infected).
Other Causes: There are a number of other causes that are common for failing installers. I have several older answers on this, but maybe this is the easier one to browse: Common causes of failed installations (setup.exe or mysetup.msi fail to install). Here is a quick extract (please do visit the link):
The most common issues seem to be: security software interference, malware infected machine, corrupted download, missing runtimes, out of disk space, blocking mechanisms on the machine from corporate policies, etc...
Other Links:
WiX, deployment and setup links
I cannot reinstall node.js on windows 10
I think your problem is not from the node.js but from the Windows installer itself.
I solved mine by following the instruction here (from the Microsoft forum).
Method 1:
Perform System File Check (SFC), and then check if this fixes the issue.
Follow the steps:
a. Press “Windows Key + Q” to open Charms Bar.
b. Type “cmd” without quotes in the search box.
c. On the left pane, right-click on the “cmd” option and select “Run as Administrator”.
d. Type ‘sfc /scannow’ without quotes and hit enter.
Method 2:
I would also suggest you to run the System update readiness command. It detects incorrect manifests, cabinets or registry data, it may replace the incorrect data with corrected version available. Follow the steps.
4. Press Windows key + X.
5. Click command prompt (run as administrator).
6. In the Administrator: Command Prompt window, type the following commands. Press Enter key after each command:
DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth
In my case, the first method solved the problem.
I'm working on a project where the goal is to be able to update a windows computer 100%. That means a program or a script that updates windows automatically with no user interaction at all. Ideally a standalone script that can be run from another script.
The reason: I need to update a lot of computers in my line of work. They can be at any patch level and everything from Windows XP to Windows 8. My goal is to start a script, wait/do something else and then find a fully patched computer.
I've solved a lot by finding ZTIWindowsUpdate.wsf in the MDT Task Sequence.
This can be used like this from an admin cmd:
cssript.exe ZTIWindowsUpdate.wsf
My problem so far is that the computer requires a reboot between some of the updates. Probably because of dependencies. ZTIWindowsUpdate.wsf needs to be run as administrator and i can't seem to find a solution to start it as administrator at reboot. Additionally if I get the script to run on startup, how do I stop it, and how do I know when its time to stop it?
Can someone help med with a foolproof solution to this problem?
Thanks!
Don't need to FULL update a Windows OS, most of the updates are not needed, most updates are not relationated with security and we can survive without they, you need to read the description of each update to understand what changes made. FULLY updating a Windows can be negative point of performance in several scenarios.
All that you need is to download your desired updates, then store it in a folder with this batch script:
#Echo off
For %%# in (*.msu) Do (
Echo: Installing update: %%#
Wusa "%%#" /quiet /norestart
)
Echo Windows Update finished.
Pause&Exit
Also you can compress the folder (the updates + the script) into a Self executable with winrar to distribute it as a standalone file.
Info:
Wusa.exe is the Windows Update commandline application.
The files are processed one by one, not all at once.
The quiet switch makes the installation silent.
The norestart switch don't restart after installing the update even if needed.
If a update is installed in the OS then is not installed again, without getting an error window or stopping the execution of the script.
PS: See Wusa /? for more switches.
I hope this helps.
UPDATE:
Another alternative is to download and install ALL the updates with WSUS utility.
http://download.wsusoffline.net/
The updates for Win7 x64 (for example) are stored here: "...\wsusoffline\client\w61-x64\glb"
PS: The "DoUpdate.cmd" batch file in the "CMD" dir of the application is what you need if need to automate the task in "background".
The simplest solution to the problem you're describing is to get your script to configure automatic logon for the built-in Administrator account, then add itself to the Startup folder. You do need to know (or reset) the Administrator account password to use this option.
There are many other possibilities, some examples are: use a startup script and psexec; use srvany to create a service that runs your script; use task scheduler to schedule your script to run automatically, either interactively or non-interactively; disable WUA, configure automatic logon for the account you're using, and add your script to the Startup folder.
Note that you'll save time and bandwidth if you can set up a WSUS server or (even simpler, and cheaper if you don't already have a Windows server) a transparent caching proxy. However this won't avoid the need to reboot during the update sequence.
You may find my script useful as an alternative starting point to ZTIWindowsUpdate.wsf, if only because it is smaller and simpler to understand.
The moast time consuming thing of a WindowsUpadate procedere is the download of the Setupfiles for the Updates. You should look into a lokaly in the network installed WUS (Window Update Server) and make sure the PC updates from the WUS. If the PCs are all in a ActiveDirectory Domain then the needed settings are very easy to manage. But if not this setting could make a simple batch-script which uses the normal windows update routine.
Another solution would be to make batch-scripts where you install the predownloaded updateFiles with the silent-switch. Allmoast every setup.exe has such a silent switch. If a update isn't needed the update stops for this upload automatically. I'm using such a batch-script wizzardy now for quiet a time now.
PS: If the Computer were from one/your compagny you should "thank" your predecessor for many hours of work to the far future.
PPS: By the way XP and Vista should be phased out. They are now realy old and for XP the already extended supporttime is axed by Microsoft next year and should only used if it is realy realy needed for one small situation where a Windows 7 isn't a solution in any way possible.
To run
cssript.exe ZTIWindowsUpdate.wsf
as Administrator after reboots, you can create a Task in the Task Scheduler with the proper permissions and to run on boot. =]
An automated way is, WuInstall. I'm using it for 1 year now and it's perfect, it actually does what it should. It's a command line tool which automatically searches, downloads and installs the updates. There are several "switches" that let you allow to customize the process. Thanks to the rebootcycle-switch for instance, updating a newly setup PC is done with ease - in one go.
Here's another way ------
Perform instructions below at your own risk:
To automate windows update these instructions may or may not work for your system however it appears to work to an extent for Windows 7 as these instructions were tested on Windows 7.
MUST READ: 1. If the step below does not work verify then you are most likely part of a domain and your security policy may not allow you to perform steps below! 2. UAC prompts were also disabled for the duration of the windows updates so the batch files can run without interruption; be careful to restore this to default when done
Caution this step will make your computer less secure, immediately remove this after your computer is completely up to date. Set a reminder for 24 hours later if need be:
1.
First you will have to make sure your computer automatically logs into a user. You can do this by clicking start menu, type "netplwiz", press enter or open the wizard, under the users tab, select your username, and un-check "require password", type your password, close this window.
2.
Create 3 batch files to start the automated process. (Open notepad paste each code into a separate notepad and perform a save as corresponding_file_name.bat)
One. Save as: any_name.bat then copy this batch file to your startup folder for the user you made auto login. (Click start > All Programs > Startup)
start "" c:\autoupdate1.bat
exit
Two. Save as: autoupdate1.bat then copy this to C:\ drive
wuauclt /detectnow
wuauclt /updatenow
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" > nul && shutdown -r -t 0
start "" c:\autoupdate2.bat
exit
Three. Save as: autoupdate2.bat then copy this to C:\ drive
ping 127.0.0.1 -n 61 > nul
start "" c:\autoupdate1.bat
exit
Restart or open the batch file in the startup folder and watch the magic begin!
3.
When it is completely done updating just delete the batch files from the startup folder & c:\ drive
Once again follow these instructions at your own risk as it can create an endless loop if you do not know how to stop this process by removing it from the startup folder or going into windows under safe-mode to remove the batch files
Final notes: If you run into issues running the batch files chances are you may have to look up how to disable UAC prompts for your Windows version
I have an installshield installer that works fine under normal circumstances. But when I run it while a particular software is running, the installer asks for a restart at the end.
Now on some research I have come to learn that a restart is asked only when the installer wants to modify files that are currently locked by other processes.
Is there anyway that I can find out which is the file installsheild wants to modify? (but cannot because it is locked by another process)
I would also like to know if it is only file modifications that affect the restart/no restart or is it also associated with registry key modifications.
You can use WhyReboot after the setup, it will show you pending reboot file and registry keys that could not be modified during the setup.
You tagged your question with "windows-installer", so I'm assuming you're using InstallShield to author an MSI installer.
Run the other software app, do a complete log of your install, like:
msiexec -i file.msi -l*vx test.log
In the resulting log, look for all lines containing "RESTART MANAGER". You will get more data on what is prompting for the reboot.
In my case, my installshield project had a "RebootPrompt" User Interface at the end of the Installation sequence with a condition "NOT INSTALLED". So all new installations would always show that Reboot prompt even if not needed.
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
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!