# Java Upgrades and the JAVA\_HOME environment variable **URL:** \ **Category:** Elasticsearch\ **Created:** [October 3, 2017, 2:42pm UTC](https://discuss.elastic.co/t/java-upgrades-and-the-java-home-environment-variable/102572 "2017-10-03T14:42:53Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![kneuse](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@kneuse](https://discuss.elastic.co/u/kneuse)\ **Post date:** [October 3, 2017, 2:42pm UTC](https://discuss.elastic.co/t/java-upgrades-and-the-java-home-environment-variable/102572/1 "2017-10-03T14:42:54Z")
We are running into a problem where upgrading Java via an automated process causes elastic search to break since the automatic process does not upgrade the JAVA\_HOME environment variable. We run elastic search in a windows environment and more specifically against Windows Server 2012 R2 box. We use system center configuration manager to perform our automated java upgrades/patching. The technical reasons that cause the upgrade to fail has to do with Java placing its bits under a folder related to the version installed. I know this is done so you can have side by side installation; however, our automated process removes the old version only leaving the latest version. Then elastic search breaks because it cannot find the java runtime. What recommends do you have for updating the JAVA\_HOME environment variable as part of patching Java? Why doesn't elastic search have a mechanism for searching out Java runtimes installed? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 31, 2017, 2:43pm UTC](https://discuss.elastic.co/t/java-upgrades-and-the-java-home-environment-variable/102572/2 "2017-10-31T14:43:19Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.