IMC's not working, JSERVER stopped and don't start

[jguse]

Hello,

There is no IMC log to debug the jserver startup, because jserver doesn't "log" anything until it actually starts up - which it won't if the permissions do not work out. The way to "debug" the startup is mentioned in the 5th post or so further up here - you can rename the client\bin startup.bat javaw.exe to java.exe, and then attempt to run startup.bat from CMD.

This will print some output, which will almost certainly be an error about jmx.password security.

EDIT: Removed the workaround of last resort, please do not use it. New Platform versrion iMC 7.3 E0705 has been released and resolves the issue in this topic entirely.

[sd219]

@jguse 

i followed this whole topic and read also all messages including the recommended workaround concerning the inheritance and all the stuff.

i also tried your highly insecure workaround with the renaming of the both startup.bat files on a test system (because all other recommended workarounds didn't work.)  and its worked as you said.

So basically i am interested in the reason why your workaround, described as highly insecure, is highly insecure and on top of that if there exists a solution right now.

So i am not the only person you might have noticed; so it would be nice if there is a solution

[jguse]

Hello,

I think all possible/known solutions to this issue have been posted throughout this topic. I've also posted earlier how to debug the jserver startup (modifying the javaw.exe to java.exe in startup.bat) and checking the output on CMD - have you tested this when using the "normal" startup.bat? If so, what output do you see in the CMD window?

The reason why startup_d.bat (which exists for debugging purposes) works, is because it starts the "java server" aka jserver process of IMC without any of the security and other options. This can be seen by comparing the two startup files. Startup_d remarks (comments out) these lines:

rem Enabling Local/Remote Monitoring and Management
rem set JMXRMI_PORT=9091
rem set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=%JMXRMI_PORT% -Dcom.sun.management.jmxremote.authenticate=false -Djavax.net.ssl.keyStore="%IMC_HOME%\security\newks" -Djavax.net.ssl.keyStorePassword=iMCV500R001

This means the SSL keystore is not set, there will be no authentication on the jmx.remote agent (which means a JMX console on IMC can be accessed remotely without login), and the jmx.remote port is not set to 9091. The port not being set might cause issues with distributed installations, though I didn't test it specifically and can't confirm.

The "Java Heap Size" is also set to 512MB by default, which will make IMC run very slowly (if at all, on larger installs). You can fix that though, by modifying the -server -Xmx512m in the following line:

set JAVA_OPTS=-server -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=512m -Dimc.home="%IMC_HOME%" -Duser.language=en -Duser.country=US -Djava.io.tmpdir="%IMCROOT%\tmp" -Dorg.apache.el.parser.COERCE_TO_ZERO=false

Here is the same line on my test system with 8GB Heap Size (out of 16GB total memory), and a few other changes that only exist in the "normal" startup.bat:

set JAVA_OPTS=-server -Xmx8192m -Xrs -XX:PermSize=64m -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=../log -Dimc.home="%IMC_HOME%" -Duser.language=en -Duser.country=US -Djava.io.tmpdir="%IMCROOT%\tmp" -Dorg.apache.el.parser.COERCE_TO_ZERO=false -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true

If you are still struggling to get the proper startup.bat working, please share the output I mentioned above from CMD, and open a support case if it's urgent.

[sd219]

As follows, you see the output of the debugging:

output from cmd

C:\Program Files\iMC\client\bin>startup.bat >2.txt
OpenJDK 64-Bit Server VM warning: Ignoring option PermSize; support was removed in 8.0
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0
Error: Password file read access must be restricted: C:\Program Files\iMC\client\bin\..\bin\jmx.password
jdk.internal.agent.AgentConfigurationError
at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.checkPasswordFile(ConnectorBootstrap.java:590)
at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:436)
at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447)
at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599)

the outfrom from the 2.txt file is empty....

[jguse]

Hello,

This error provided matches the issue I've described in previous posts here.

It means that the security settings on your jmx.password file are not correct. This file must be configured with Full Control for the local Administrator Group and absolutely no other permissions.

If you are unable to figure it out, can you please post a screenshot of the jmx.password file Security settings (permissions)?

[sd219]

i am absolutely capable of configuring the jmx.password file concerning the mentioned security settings, cause it is my daily business.

But as i said before, it is not possible to delete the specific application group (the following picture is in german)

So it is like all the other people before described this issue.

The jmxpassword file is configured with Full Control for the local Administrator Group but it is definitely not possible to delete the other rights (Allen Anwendungspakete)

So what should i do next?

[jguse]

Hello,

I've been unable to reproduce that particular issue in the Lab, so I am not sure how exactly to solve it, and support cases I've seen got resolved by removing all the excess permissions. That's why I've suggested to double-check the permissions, and sorry I didn't realize you had already done it and got stuck on ALL APPLICATION PACKAGES.

I am not sure why you can't remove this permissions, and have not found too many good explanations for this behavior online. However there is this post.

We have been informed by Microsoft that this behavior is "by design".

ALL APPLICATION PACKAGES supports UWP apps and if you assign it permissions, Windows then attempts to "protect" them.

So, not a bug. An undocumented feature!

It's for Windows 10, and I don't know if that 'feature' applies to Windows Server as well.

An article from Microsoft here about a different issue (where this permission is actually missing) and they recommend steps there to check if permissions were manually configured in the Registry or via Group Policy.

Maybe the steps mentioned there can help you figure out if you have Registry or Group Policy settings that might be applying the permission. Group Policy is probably the most likely candidate... quoting the article:

Determining if Group Policy is being used to manage permissions

1. Logon to a PC as a user experiencing the problem
2. Open an administrative command prompt then run the following command:
   
   > gpresult /h <path>\gpreport.html
    
3. Open the file gpreport.html and expand the following path:
   
   Computer Settings -> Policies\Windows Settings\Security Settings. look for "File System" and Registry. If these exist then GP is assigning permission. You must edit the GP to include the necessary permissions for the All Application Packages group.

Can you check if such settings might be applying permissions?

Hope that helps.

[UFGD]

This worked for me! Thank you

Best,

Renato

[jguse]

Hello everyone,

Good news, iMC 7.3 E0705 has been released in the meantime, which is not affected by this issue and should resolve it for you when you upgrade. Please open a support case if there are still issues with the jserver starting post-upgrade.

iMC Standard: https://h10145.www1.hpe.com/downloads/SoftwareReleases.aspx?ProductNumber=JG747AAE

iMC Enterprise: https://h10145.www1.hpe.com/downloads/SoftwareReleases.aspx?ProductNumber=JG748AAE

If you were previously using the last resort workaround with startup_d.bat, please revert to the original startup.bat.

[MilesT]

I have this same issue and tried resetting the permissions for jmx.password as per previous suggestions but had no success.

After downloading the latest E0705 update, it would fail part way through the install and the dma log would show an error with the jmx.password file again so I just set full permission for Everyone and it finally finished the upgrade successfully.

On a domain network, should the permissions for this file be domain\Administrators Full Control as well as Local Administrator Full??

I can finally log into it again, hooray!

[jguse]

Hello,

The permissions of the file do not need to be touched if you upgrade to iMC 7.3 E0705. iMC will set the permissions correctly now during the upgrade - which should be Full Control for only the local Administrators group (and no other permissions whatsoever).

[LSG]

hi Justin

i see this is an old issue, i looked at this and saw that i do not have a jmx.password file.  so when trying to run that command it cant find the ile cause it doesnt exist.

[jguse]

Hello there,

If you don't have a jmx.password file, then it is unlikely that you are on 7.3 E0703 version that is affected by the same issue mentioned here. Please start a new thread if you have issues with jserver startup on any other version.

If you happen to be on 7.3 E0703 and affect by this, then upgrading to E0705 is the most effective way to resolve it.

If you are running a version prior to 7.3 E0703, upgrade directly (from any 7.3 E0605 version, including patches/hotfixes) to 7.3 E0705, skipping E0703 entirely.

Note that if you run Server 2008 / MSSQL 2008 / RHEL 6.x, you should perform a migration before upgrading to E0705 - please follow the IMC Windows/Linux Migration Guides included in the "manual" folder of the latest iMC software download package.