I have a solution to a huge issue that people are experiencing. Having vertex 8.0 installed on a Windows server OS and trying to update Java on the regular.
I have included an example of our script and a photo of our task trigger start up in Windows Task Scheduler for your help.
Symptom:
When updating Java Developer and Java Client on a windows server. New Java 8.0 update *.* will uninstall the previous version of Java and try to start vertex back up after the server has been rebooted. This will fail, due to the new directory of Java being different from the previous version and vertex will no longer load. This is due to tomcat having the incorrect directory in the tomcat vertex service in windows.
Breakfix/Home Brew Resolution:
Due to java, not sticking with the same directory when they update java themselves. Every single time when you update java, you need to find the directory in which the newer version of java resides in and change the service. I am a PowerShell person at heart, due to this being so windows embedded, we decided to move in that direction to resolve the issue.
Beginning challenges:
Making the change automatically without any user interaction and having the server know exactly when do I need to run this script in order to make the change necessary so it doesn’t start whenever it wants to.
First item on the PowerShell script, accesses add/remove programs and pulls the last time that Java Dev or Java Client gets installed on the system and places it into two variables called $vardate1 and $vardate2.
Next item, the system pulls two types of dates. One being the current date ONLY formatted to match the add/remove date formatting in windows. One takes the same formatting of the date and subtracts one day to the current date in which the script runs. Why did we do this? Due to us patching at 11pm at night we might have an overlap in days in which we patch the server. So earlier enough it could have been patched the previous day or it could be the same day. Depending on time, bandwidth and speed etc. These values are being held in $getdatecurrent and $getdateprevious.
Brackets for the if statement is comparing the $vardates and $getdate variables to see if they match the current date. If so the server must of patched right? Correct, so let’s change the Java directory because it will be wrong and vertex will now not start properly.
Inside of the brackets are the meat and potatoes of the script itself.
First item stops the vertex services in which control vertex. Start-sleep in the next statement just allows the script to “rest” for 60 seconds before proceeding to the next step. The next step is the most important, the get-childitem statement. This is looking in the C:\Program Files\Java directory for the last written directory, because in theory this will not be recently updated unless it’s been updated. You want to make sure that you get the “FULLNAME” or “FULLPATH” or the directory so tomcat knows where to locate the files needed, this is imported into the $vertexjava variable.
Next item is important as well, set-itemproperty this allows us to access the windows registry in which the tomcat service for SAP holds all the information for starting and stopping the service.
Shortcut for the registry key is HKLM:\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\vertex80\Parameters\Java the key name is Jvm normal string style key.
Now, when you open the key it will say C:\program Files\Java\jre1.8.0_202\bin\server\jvm.dll. When we pulled the information for the get-childitem for the directory earlier we only received the part for the java directory ONLY and not the “\bin\server\jvm.dll.”
What is needed is to keep that information and insert it into the directory information that you obtained in the get-childitem call you made earlier to the $vertexjava variable.
In powershell to use a varible infront of using static data behind it you have to place the varable name in {} brackets like so "${vertexjava}\bin\server\jvm.dll.” and that will be the data that you insert into your registry key.
Next step is to allow the script to sleep another 60 seconds to make sure the changes took and the final step is to start the service back up. If everything was successful you should have a server that gets patched with Java and ONLY updates the registry key unless it is patched with Java on that particular patch cycle.
Now, how do you make it happen automatically? Throw a task in windows task scheduler, with a trigger to start when the server starts with a 10 minute delay AFTER the server reboots and comes back up, to run the powershell script. Make sure you run this as a either SYSTEM account on the box and/or an administrator account that an administrator has setup in your AD environment. Keep in mind since this is starting up every single time the server is starting, will the script trigger? Of course it will however, we placed the break in the script it will only activate unless the update date is only matching when we do patching it must match.
Please note the code below is the powershell script that we have used. There was no option for PowerShell in the code selection window so just to let everyone know this is powershell.
So, at the end of the day if your SAP Vertex Tomcat is getting patched with Java Runtime and Java DEV and when the server is being patched/rebooted. After the reboot if Tomcat is never starting properly with the newer version of correct Java this will be the fix for you.
If anyone has any questions or if I can help other companies or business that are struggling with this issue just reply back and I can try to take them one at a time as they come in.
I have included an example of our script and a photo of our task trigger start up in Windows Task Scheduler for your help.
Symptom:
When updating Java Developer and Java Client on a windows server. New Java 8.0 update *.* will uninstall the previous version of Java and try to start vertex back up after the server has been rebooted. This will fail, due to the new directory of Java being different from the previous version and vertex will no longer load. This is due to tomcat having the incorrect directory in the tomcat vertex service in windows.
Breakfix/Home Brew Resolution:
Due to java, not sticking with the same directory when they update java themselves. Every single time when you update java, you need to find the directory in which the newer version of java resides in and change the service. I am a PowerShell person at heart, due to this being so windows embedded, we decided to move in that direction to resolve the issue.
Beginning challenges:
Making the change automatically without any user interaction and having the server know exactly when do I need to run this script in order to make the change necessary so it doesn’t start whenever it wants to.
First item on the PowerShell script, accesses add/remove programs and pulls the last time that Java Dev or Java Client gets installed on the system and places it into two variables called $vardate1 and $vardate2.
Next item, the system pulls two types of dates. One being the current date ONLY formatted to match the add/remove date formatting in windows. One takes the same formatting of the date and subtracts one day to the current date in which the script runs. Why did we do this? Due to us patching at 11pm at night we might have an overlap in days in which we patch the server. So earlier enough it could have been patched the previous day or it could be the same day. Depending on time, bandwidth and speed etc. These values are being held in $getdatecurrent and $getdateprevious.
Brackets for the if statement is comparing the $vardates and $getdate variables to see if they match the current date. If so the server must of patched right? Correct, so let’s change the Java directory because it will be wrong and vertex will now not start properly.
Inside of the brackets are the meat and potatoes of the script itself.
First item stops the vertex services in which control vertex. Start-sleep in the next statement just allows the script to “rest” for 60 seconds before proceeding to the next step. The next step is the most important, the get-childitem statement. This is looking in the C:\Program Files\Java directory for the last written directory, because in theory this will not be recently updated unless it’s been updated. You want to make sure that you get the “FULLNAME” or “FULLPATH” or the directory so tomcat knows where to locate the files needed, this is imported into the $vertexjava variable.
Next item is important as well, set-itemproperty this allows us to access the windows registry in which the tomcat service for SAP holds all the information for starting and stopping the service.
Shortcut for the registry key is HKLM:\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\vertex80\Parameters\Java the key name is Jvm normal string style key.
Now, when you open the key it will say C:\program Files\Java\jre1.8.0_202\bin\server\jvm.dll. When we pulled the information for the get-childitem for the directory earlier we only received the part for the java directory ONLY and not the “\bin\server\jvm.dll.”
What is needed is to keep that information and insert it into the directory information that you obtained in the get-childitem call you made earlier to the $vertexjava variable.
In powershell to use a varible infront of using static data behind it you have to place the varable name in {} brackets like so "${vertexjava}\bin\server\jvm.dll.” and that will be the data that you insert into your registry key.
Next step is to allow the script to sleep another 60 seconds to make sure the changes took and the final step is to start the service back up. If everything was successful you should have a server that gets patched with Java and ONLY updates the registry key unless it is patched with Java on that particular patch cycle.
Now, how do you make it happen automatically? Throw a task in windows task scheduler, with a trigger to start when the server starts with a 10 minute delay AFTER the server reboots and comes back up, to run the powershell script. Make sure you run this as a either SYSTEM account on the box and/or an administrator account that an administrator has setup in your AD environment. Keep in mind since this is starting up every single time the server is starting, will the script trigger? Of course it will however, we placed the break in the script it will only activate unless the update date is only matching when we do patching it must match.
Please note the code below is the powershell script that we have used. There was no option for PowerShell in the code selection window so just to let everyone know this is powershell.
$vardate1 = Get-WmiObject -Class Win32_Product | Where-Object {$_.name -like "Java 8*" } | Select-Object -ExpandProperty InstallDate
$vardate2 = Get-WmiObject -Class Win32_Product | Where-Object {$_.name -like "Java SE*" } | Select-Object -ExpandProperty InstallDate
$getdatecurrent = (get-date).ToString("yyyyMMdd")
$getdateprevious = ((get-date).AddDays(-1)).ToString("yyyyMMdd")
if (($vardate1 -eq $getdatecurrent) -or ($vardate2 -eq $getdatecurrent) -or ($vardate1 -eq $getdateprevious) -or ($vardate2 -eq $getdateprevious)) {
Stop-Service -Name "vertex80" -Force
start-sleep -Seconds 60
$vertexjava = Get-ChildItem "C:\Program Files\Java" | sort LastWriteTime | Where-Object {$_.Name -like "jre*" } | Select-Object -ExpandProperty Fullname -Last 1
Set-ItemProperty -Path "HKLM:\software\Wow6432Node\Apache Software Foundation\Procrun 2.0\vertex80\parameters\Java" -Name "Jvm" -Value "${vertexjava}\bin\server\jvm.dll"
start-sleep -Seconds 60
start-service -Name "vertex80"
}
So, at the end of the day if your SAP Vertex Tomcat is getting patched with Java Runtime and Java DEV and when the server is being patched/rebooted. After the reboot if Tomcat is never starting properly with the newer version of correct Java this will be the fix for you.
If anyone has any questions or if I can help other companies or business that are struggling with this issue just reply back and I can try to take them one at a time as they come in.
- SAP Managed Tags:
