The rule of thumb seems to be that you leave a profile/server aside to handle the adminConsole, so that you will always have adminConsole, even if other applications fails to startup. However, in practice, most development / test WebSphere environments that I have come across has everything deployed to 'server1'. In this situation, the applications starting up automatically is even more dangerous as they can make even the adminConsole unavailable to you!
If you get stuck with the application bringing down adminConsole, solution is to stop the application from starting up automatically on server startup. To do this, you need to locate deployment.xml file in your WebSphere installation folder:
$drive/$WebSphereInstallation/profiles/myProfile/config/cells/myCell/applications/myApplication.ear/deployments/myApplicationName
Look for 'deployedObject' that is related to your application, and under it, locate 'targetMappings', and change 'enabled="true"' to 'enable="false"'.
eg: <targetMappings xmi:id="DeploymentTargetMapping_1147899429698" enable="false" target="ServerTarget_1147899429698"/>
Next time when you start the server, the offending application will not startup, giving you a chance to use adminConsole, and identify a fix.
Powered by ScribeFire.