Im trying to install AX 2012 Async server on a machine with
OS: Windows Server 2012 R2
IIS:8.5
One of the prerequisites gives me the following error as shown in the screenshot
I have installed the script with the command Import-Module C:\"Path to Module" -Verbose (as mentioned in the above image), however still the prerequisite persists I have tried restarting the server. But to no avail.
This is the screenshot of running the command:
I think the command is not being run successfully , The alternative version of the command AddPSSnapin throws an error. What seems to be the issue here?
EDIT: This is the log file prerequisite check:
2016-02-15 16:17:25Z Performing a check for pre-requisite 'Web Server (IIS) Administration module'.
2016-02-15 16:17:29Z Check if WebAdministration module is available
2016-02-15 16:17:29Z No
2016-02-15 16:17:29Z Trying to add snapin for older version of Windows.
2016-02-15 16:17:29Z Unable to import web administration module or snapin. Please install the IIS web administration module or snapin for PowerShell
AS shown here it seems to be trying to add snapin and then failing the prerequisite.
For some reason the PSModulePath system environment variable doesn't seem to be set on your server. Because of that you can load the module when you specify its full path, but not when you specify just the name (Import-Module WebAdministration). The prerequisites check of the installer most likely checks the presence of the module by name as well, since $env:PSModulePath usually contains more than one location, and it shouldn't matter which of them actually contains the module.
Set the system environment variable PSModulePath to %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules and the problem should disappear.
Related
I have a WebSphere Application server (WAS) installed in the path /opt/IBM/WebSphere.
Is it possible to get the installation path using OS user wsadmin?
I need to get that installed directory path from shell script.
If you're in a profile directory (or always know where one is,) you could check variables.xml, which exists at /config/cells/(your_cell_name_here)/nodes/(node_name_here)/variables.xml for the value of WAS_INSTALL_ROOT. For example (not necessarily the cleanest):
INSTALLROOT=$(grep "symbolicName=\"WAS_INSTALL_ROOT\"" variables.xml | grep -o "value=\"[^\"]*" | cut -b8-)
There is also an installation registry, which is /opt/.ibm/.nif/.nifregistry for WAS before 8.0 and /opt/.ibm/.was.installlocations.registry for 8.0 and above, however these are created and edited by the installation wizard so they may not be 100% accurate to what's installed on the system. This developerWorks answer explains a little more about those files.
Recently, I tried to create self-signed certificate for Azure Service Factory accordingly with Microsoft's manual:
Azure Docs: Secure a Service Fabric cluster, step 2.5, 02/05/2016
But command Invoke-AddCertToKeyVault failed with the next error:
Invoke-AddCertToKeyVault : The term 'Invoke-AddCertToKeyVault' is not
recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
I think that Azure Powershell successfully installed on my machine because I was able to login into my Azure account by running Login-AzureRmAccount. Also $env:PSModulePath says that Azure Modules path added to path variable (accordingly with the article: Azure Docs: How to install and configure Azure PowerShell, 04/22/2016). Here they are:
...\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\;
...\Microsoft SDKs\Azure\PowerShell\ServiceManagement\;
...\Microsoft SDKs\Azure\PowerShell\Storage\;
Also, I have restarted my PC after installing Azure PowerShell.
It is possible that I have missed something, but I am stuck with it. How could it be resolved?
That commandlet is in the package that should be imported -
Import-Module "C:\Users\chackdan\Documents\GitHub\Service-Fabric\Scripts\ServiceFabricRPHelpers\ServiceFabricRPHelpers.psm1"
That is its implementation, by the way, for a reference that it even exists :). Try Import-Module and it should work.
We have a Jenkins instance running on Ubuntu that has several slaves in different systems. One of them is a Windows 7 host, having jenkins slave instance configured as a service.
We have a problem that when that machine is rebooted, master Jenkins doesn't realize it's gone. It looks to be just fine in the nodes view. Then, when a build is issued that is supposed to use that slave it gets stuck. If that is stopped, the next build fails immediately
Caused by: java.util.concurrent.TimeoutException: Ping started at 1457016721684 hasn't completed by 1457016961684
... 2 more
[EnvInject] - [ERROR] - SEVERE ERROR occurs: channel is already closed
When the slave has started up and it tries to connect back to master, connection is refused, and in the logs there is an error saying connection with that name already exists:
Server didn't accept the handshake: xxx is already connected to this master. Rejecting this connection.
There is issue JENKINS-5055 which claims a fix was committed allowing the same JNLP slave to reconnect without getting rejected, apparently this commit, and according to changelog, it was introduced in version 1.396 (2011/02/02). We are however using version 1.639 and seeing this. Somebody else seems to be seeing it as well. By looking at current codebase, I see where the error is coming from, but don't see the fix done in Jenkins-5055.
Any ideas on resolving this?
Edit: also asked on jenkins user mailing list, but no responses.
We faced the same issue. Used https://wiki.jenkins-ci.org/display/JENKINS/slave-status as workaround
Reinstalling the slave on a Windows Server 2012 R2 machine shows no signs of this behavior, so it seems that either there was a mistake done during installation steps or this is something caused by using a workstation Windows version.
Regardless, here were the steps to get it working, assuming a brand new installation of Windows, with no network connectivity, and master instance using a self-signed certificate:
Install JRE on the machine. If you have 64-bit operating system, install both 32-bit and 64-bit, otherwise go with 32-bit. Download link here
Install .NET 3.5 on the machine. This is needed by the Jenkins service. You can follow the steps outlined by my other answer for this.
Install Jenkins using Windows installer (.zipped) to C:\Jenkins. It can be downloaded from here.
Check your installation is responding by navigating to http://localhost:8080 . In case of trouble, check for logs in the jenkins folder. If there is a port conflict, edit jenkins.xml and change the httpPort to something else.
From the Windows computer, navigate to your master jenkins and configure a new node there.
Start a slave agent using Java Launch Agent in configure -> node screen (you need to be still using your Windows slave computer)
You should see a visible window opening. From there, select File -> Install as a service. (details and screenshots) If you experience an error without proper explanation, confirm .NET 3.5 is properly installed. If you see "WMI.WmiException: AccessDenied", save the jnlp file locally and start it from administrator prompt or otherwise with elevated privileges (details).
From the Administrative tools -> Services, stop and disable the Jenkins service, and stop Jenkins Slave Agent but leave it on Automatic so it will start up when starting up the computer.
This is only relevant if you're using a self-signed or otherwise problematic certificate:
download the previously mentioned Java Launch Agent file (.jnlp file) again and save it to C:\jenkins
open c:\jenkins\jenkins-slave.xml to your editor
change it to refer to your local .jnlp file by changing jnlp url parameter (file:/C:/jenkins/jenkins-slave.jnlp)
add -noCertificateCheck to parameters
replace the -secret parameter with -auth "user:pass", since otherwise automatic url get parameters will be added which will mess finding the .jnlp file
Start the Jenkins Slave Agent service again
For problems with jenkins slave service, check out jenkins-slave.err.log. For Windows Server 2012 R2, you can get the functionality of tail by using Get-Content .\jenkins-slave.err.log -Wait -Tail 10 in Powershell prompt. For older versions of Powershell, leave out -Tail 10.
I just installed nodejs on one of my build servers (Win Server 2008 R2) which hosts a Bamboo remote agent. After completing the installation and doing a reboot I got stuck in the following situation:
The remote Bamboo build agent is running as a windows service with user MyDomain\MyUser. When a build with an inline powershell task is executing it fails with the error (from the build agent log):
com.atlassian.utils.process.ProcessNotStartedException: powershell could not be started
...
java.io.IOException: Cannot run program "powershell"
...
java.io.IOException: CreateProcess error=2, The system cannot find the file specified
Loggin on to the server as MyDomain\MyUser, I have checked that powershell is in the path:
where powershell
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
I have tried to restart the service and reboot the machine multiple times. No luck. The only thing that works is if I execute my scripts as a bat file with an absolute path to powershell - but I do not want that.
I have searched for solutions on this, but even though this one seems related: Hudson cannot find powershell after update to powershell 3 - the proposed solutions do not work.
What am I missing here?
If you do a default installation of nodejs you will see that it adds nodejs and npm to the path. Sometimes I have seen that the installer adds a user variable named PATH - it might be that the Bamboo agent decides to read the user path without "merging" it with the system path. I think it would be worth a try to give that a look.
As per Atlassian support page, this is related to a bug in Java Service Wrapper. I tried Workaround-2 since there was no user PATH variable in my system. I had to uninstall bamboo agent service and Java 64 versions from the agent machine to apply the workaround-2.
I'm attempting to get my Jboss Server running as a windows service using the JbossService.exe, and I had it working until I uninstalled it (with ./JbossService -uninstall JbossService), and now, while it will install and the service will appear in the windows service list, attempting to start it will only yield the error message:
"The JBossService on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service."
If it helps, the command I'm using to install it is:
./JBossService.exe -install JBossService "$java_home\jre\bin\server\jvm.dll"
-Xmx128m -Xrs -Djava.class.path="$java_home\lib\tools.jar;$jboss_home\bin\run.jar"
-Duser.timezone="Australia/Sydney"
-start "org.jboss.Main" -stop "org.jboss.Main"
-method systemExit -out "$jboss_home\server\default\log\stdout.log"
-err "$jboss_home\server\default\log\stderr.log"
-current "$jboss_home\bin"
Any ideas would be appreciated. If more information is required just let me know.
Are you using Cygwin? If not, this could be due to the fact that environment variables are referenced using %%, not $, on Windows. You might try the following instead:
JBossService.exe -install JBossService "%java_home%\jre\bin\server\jvm.dll"
-Xmx128m -Xrs -Djava.class.path="%java_home%\lib\tools.jar;%jboss_home%\bin\run.jar"
-Duser.timezone="Australia/Sydney"
-start "org.jboss.Main" -stop "org.jboss.Main"
-method systemExit -out "%jboss_home%\server\default\log\stdout.log"
-err "%jboss_home%\server\default\log\stderr.log"
-current "%jboss_home%\bin"
Even if you are using Cygwin, the $ notation still might not work if, for example, these parameters are being stored in the Registry and then read later from the OS (which does not understand Cygwin notation).
While this does have a valid answer, one reason this happened to me recently is because the user the JBoss Windows Service was running as had certain active directory permissions revoked from the server (in this case, administrative-like permissions); it could no longer access certain directories it required in order to process (the Java bin folder, for example).
Once the user the service ran as was added back to the appropriate Windows User Groups, the JBoss Windows Service started with no issues.
In my case, JAVA_HOME was not set. Once I did that, Automatically windows Services started.
:)