[Looking for Charlie's main web site?]

How to solve common problems with applying ColdFusion updates

Note: This blog post is from 2016. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
You want to apply some update to your current version of CF. While the ColdFusion admin has a simple update UI mechanism, what can you do if the update fails to apply? Indeed, how can you know if it DID fail? The answer may be simple on the surface, but not obvious to most. (And you'll likely be in panic mode.)

Many find after applying a ColdFusion update that either CF won't start at all, or they can't access the ColdFusion Admin, or some part of CF or their app doesn't work. Or perhaps the problem may not become clear for hours or even days.

The problem may be simply that there was an error in the update process CF did, and it may be rather easily confirmed and resolved. In this post, I share several tips and observations to help resolve this, based on my years of providing remote CF troubleshooting support.

The TLDR version:
  • Check the ColdFusion update log--not logs in the normal CF "logs" folder, but the update's "install" log, and a specific table of successes and errors there. More detail below.
  • And if there ARE errors, try stopping CF (and its related services) yourself, and then try the update again. Again, more below.
  • Finally, if that still fails, then manually apply the update from the command line. I share more on that below also.

If that's enough to get you going, great--especially if you ARE in panic mode! (If the "problem" you need to solve, instead, is that you can't get CF to show you updates because you're behind a firewall preventing outbound internet access, I help with that also, toward the end.)

For most people, though, even those "simple things to do" can prove challenging (and understandably so). And you may find different resources on the web offering perhaps truncated discussions of the topics, which is why I elaborate on things in this post.

And even if you're in a panic, it may take only about 10 minutes to read this whole post. (You can also hire me to help instead, of course. See the links above or below.) Hope the info to follow is helpful for you.

For the more visual folks, I also addressed much of this in an hour-long presentation I gave at various events in recent years, the last being recorded on the CFMeetup (as linked to there).

Here are the sections below:

Check the update log...yes, there is one, but it's oddly formatted

So the first thing to do after you update ColdFusion (10 or greater) is to check the update install. And I do NOT mean here the logs in the CF "logs" folder. There are lines among those which will tell you THAT the updater applied but they will not tell you IF the update was applied successfully.

So yes, there is a log devoted to tracking the success of the update, and it's in a different location (and oddly formatted). And you really should check it even if the update seems to or reported itself to be "successful". It's easy to do once you know how:

  • See the [cf]\cfusion\hf-updates\ folder. (I use [cf] to generically refer to the cf10, 11, 2016, or 2016 folder.) And in there, find a subfolder named for the number of the update you applied (like hf-10-00021, or in 2016, like hf-2016-00002-299200).
  • There is a log in there whose name has the date/time of the install (or uninstall) of the update. note that I am NOT referring to the hotfix_filelist.log (If there is no update log in that folder, did you run the manual update discussed below? Note that the log is not written until you click "done" in the jar's UI. Or if you run multiple instances, look for the log in the hf-updates of the cfusion instance, not the other instances.)
  • And in that update install (or uninstall) log, about 100 lines down from the top (do NOT go to the bottom to look for it) is a table with a count of successes, warnings, and errors.

The table may look like this:

Summary
-------

Installation: Unsuccessful.

373 Successes
1 Warnings
0 NonFatalErrors
1 FatalErrors

If the table reports all successes, great. Your update took. You can move along with your day. :-)

If it reports even one error or nonfatal error (and even it only reports warnings), then something was amiss with the update, and you can try to read through the remainder of the log to see if among the several hundred remaining lines it may explain what happened. That can be challenging because in some updates, many of lines in the log may have the word "error" or "warning" in referring to files that were changed in the update.

But do try to find what in the log may have been the problem.

The most common cause of ColdFusion update failures: CF did not stop

In nearly all cases when there is an error in the update, the answer is surprisingly simple (and it may even report it plainly if you look), but knowing where to look is challenging enough. Addressing the problem can be even more challenging for most, but it too is fairly simple once you see the options.

So the most common reason I find is that the update failed to stop the instance (of CF or other related processes). The log may even report it specifically on lines like the following:

  • Failed to copy hotfix files:C:\Users\cfuser\288630.tmp\dist\cfusion: Failed to copy the hotfix files to the target location. Retry installation after ensuring that the server is not running or files are not locked by the server.
  • Failed to copy the hotfix files to the target location:C:\ColdFusion11\cfusion FATAL ERROR - C:\ColdFusion11\cfusion\jetty\webapps\PDFgServlet\Resources\bin\HTML2PDFConverter.exe (The process cannot access the file because it is being used by another process)

Another error you may see is:

Failed to delete directory: Ensure that the server is not running or files are not locked by the serve

And there are others you may see. (I welcome comment pointing out others, so that I can add them here and hope people find this post while searching for such errors.)

So here's the issue: the update mechanism (in the CF Admin) is supposed to stop the instance, then backup the files to be changed, update them, and then bring it back up.

But if the instance does NOT come down (or not fast enough), then when the update tries to proceed with replacing or removing files to be changed, it cannot (because the files are locked by the OS), and that's why the update fails--not always, but nearly always, in my experience. We can debate whether Adobe should improve the process of the update so that it GUARANTEES that CF is down before proceeding, but until that's resolved, this info applied.

(And the update mechanism has improved. In CF10, a common problem is that once you click the "ok" button to let the updater run, you will find that within about 15-30 seconds, your CF Admin will refresh on its own, and if CF is not yet back up, you will get an error reporting "" or "Service Temporary Unavailable" and that "The server is temporarily unable to service your request". In that case, it may just be that it tried to refresh before it was back up. Just try refreshing the CF admin, or check if CF is indeed back up. In CF11, they fixed that so that the installer reports that it's checking the status and should let you know when it's all done. I say "should", because sometimes it does not, even though the update is indeed finished and worked. Again, if CF is back up, try refreshing the admin and see if you get a prompt to login then check if the update applied.)

Related to all this, one trick I recommend (in anticipation of both problems above) is that you should always arrange to watch the CF process(es) before and during the update (at the OS level) to confirm that the CF instance (at a minimum) does indeed stop and start. In the case of Windows, you can watch in the Services panel, which you can refresh with F5 or the Action>Refresh menu command or the Refresh icon on under the menu.) Or in any OS watch the list of running processes to see ColdFusion disappear and reappear.

If you do see it go down and come up, there's a greater chance that the update will take. Still, you may miss whether it happens, or there could still be errors, so again do look at the update log to confirm the success or failures.)

The most common REASON the update process does not stop CF services, and a solution

[Update] This section is new since I first wrote this post in 2016.

The most common REASON that the CF service won't stop during the update process is if a) you are trying to do the update from within the CF Admin (which should be ok), but b) especially on Windows, when the user running the CF service has been changed from the default "local system" user to soem other user.

The problem is that in doing that update from within the CF Admin, CF will launch a java.exe to perform the update (see below), and it will run as THAT user--who won't have permissions by default to start and stop the CF services!

Sadly, Windows offers no easy way to give permission to control whether a user can start/stop services, the way it allows changing of file/folder permissions.

But here's good news for this problem: there is a nifty free tool called Service Security Editor. With that, you CAN easily (and safely) change any service to allow a given user to start and stop it. And I plan to do a blog post on it and this process, but until then:

  • a) check out the tool (free, no installer, and see the site there for how easy it is to use--offered in words and video
  • then b) use it to change ALL the CF services (even if still running as "localsystem") to be controllable by that user running the CF application server service
  • then c) you should find that when you run the update (from the CF Admin), it should now work as expected
If this does not solve the problem, read on, which is the remainder of this post as I originally wrote it.

A solution that will work for most: just stop CF's related services, then restart CF, and try the update again

So if there were errors, and either the log tells you that CF did not stop or you're just not sure, the solution nearly always is just that you'll want to stop all processes that may be pointing to CF files.

That means at least stop CF's related services (like the ColdFusion "Add On" Service, and CF's ".NET" and "ODBC" services (if installed). You may want to stop your web server also (unless you are on CF 10 or 11 and use that to access the CF Admin).

Then you may also want to restart CF itself for good measure (especially if it's been up for a long time before you try this), just to make sure it can go down when the updater does it. Sometimes, this one step alone (of restarting CF yourself) may be enough to let the update run if you try it again!

It's just that sometimes when you stop CF at one point in time, it may go down faster than when the updater tried to stop it at a previous point in time. The matter of why CF sometimes is slow to go down or come back up is really a topic for another blog post.

My point, though, is that you may find that if you do stop and start it, you may well find that you can just go ahead and apply the update via the Admin as you did before and it may "suddenly" just work!

If it does work, skip down to "Is CF running now after the update? Great!", below.

But if that attempt to update STILL has errors, then it's time to move to the next step.

When that still doesn't work: stop CF (and related services) and install the update from the command line

For many people, for whatever reason, they may find that they just can't get the update to run from within the UI of the CF admin, as they find it keeps failing. For them, the next solution is that will need to stop CF themselves and keep it stopped for the update to work.

Of course, there's one REALLY big problem with stopping CF: you cannot then go into the CF Admin to run the updates as you did before. Doh! And this is where most get stuck.

The good news is that you can run the updates yourself, from the command line. That's where still more get stuck, but it's really quite simple, and once you are guided through it, you may even opt to always apply updates this way to avoid the above hassle!

Before proceeding, again, stop CF and all related services, as discussed above. The point is, once CF is down there's then less reason the files should be locked when the update runs. (And you should make sure you really no longer see coldfusion running as a process.)

Proceeding with the command line install of the update

If you can "download" the update from the CF Admin (or by downloading its jar file directly from Adobe, as offered in each update technote), you can instead run the update from the command line.

As for running the CF update from the command line, you have two choices.

[Update: Since writing this post in 2016, this "second choice" is a new option, as of CF2021]

The original option I discuss below, of running the java -jar against the update's jar will work in any CF version, including CF2021 and above, so if you are familiar with it already and may prefer it, you can keep using it.

But note that as of CF2021, Adobe also added a command line tool called cfpm. While that's used primarily to perform management of "packages" (or "modules") that control CF features, it can ALSO be used to perform a command line update of CF itself (and/or the packages). For now, I will simply point you to the docs on that cfpm tool, and some of the CF 2021 update technotes also discuss this approach.

The rest below is what I had written originally.

As for just running the command line install (in any CF version) basically, you just want to get to the location where the updates are placed when downloaded by the CF Admin ([cf]\cfusion\hf-updates), and from there run the Java command with the "-jar" argument to point to the update jar to be run. In Windows, it's probably wise to open the command prompt as administrator.

[Update in 2022: Note that since CF2021 update 3 and above, Adobe is now downloading that update jar to a different folder by default, [cf]\bundles\updateinstallers.]

Here's an example of how that might work, on an update of CF2016 on Windows. You may need to change the paths, of course.

cd C:\ColdFusion2016\cfusion\hf-updates

C:\ColdFusion2016\jre\bin\java -jar hotfix-002-299200.jar

(Again, if installing CF2021 update 3 or above, find and run that instead in [cf]\bundles\updateinstallers.)

This will open a java-based installer (which looks quite a lot like the CF installer itself), and it will go through a few screens to perform the update.

For more, see Adobe's blog post on command line update installation. The concepts in the post apply to CF10, 11, 2016, or above.

Even so, I will add a couple of tips for you to keep in mind, and a couple gotchas you may want to consider before proceeding:

  • While the update process says it will try to stop CF, again I would still stop CF myself before running the manual update. (And no, there's no harm that it's already stopped when the update says it will try to stop it.)
  • You might still want to use the suggestion I made above to watch the services/processes to confirm that CF does go down and come back up, especially if you did not think to stop CF yourself.
  • Indeed, do make sure that CF does come back up. While the installer SHOULD start CF, I have seen times when it did not, even when there were no errors in the update. In that case, start it as a service like you normally would.
  • If you notice all the related CF services are running, but NOT CF, beware that the command line installer may have started CF NOT as a service but as a process, running under YOUR account. That's not a good thing. See the second after next.
  • And if all seems well, you SHOULD still check the install log to confirm the count of successes and errors. It will be created just as described above, and put in the same place, regardless of whether the update is run from the CF admin or via this command-line java installer.

For many, that's all they needed. If it's working, great. Proceed to "Is CF running now after the update? Great!", below.

But there are some gotchas to beware when doing the command line update.

A gotcha to beware for cmd line install: make sure to use the same bit-level Java that CF is using!

If you DO use the manual command-line installer, there are a couple of potential gotchas.

The first can happen if you have different Java versions installed, including one that's been implemented so that you can just type Java at the command line and it works (reports the java help in reply). If you proceed to use that for the cmd line installer above, the installer may well launch and seem to run to completion.

But then you may find that CF won't start. You may even find that (per the discussion above) the update log had no errors, and yet the CF service won't start! You may panic.

But here's a trick: try starting CF from the command-line (by going to the /cfusion/bin folder and running cfstart). Does it report "error loading" the jvm.dll. What the heck happened?

This tripped me up the first time it happened. I ultimately figured it out: the client I was doing the cmd line installer with had for some reason implemented a 32-bit Java JRE on their machine, but CF was implemented as 64-bit (and was itself pointing to a 64-bit JVM).

There's nothing WRONG with having two different bit-level JVM's, as in this case, if you have something that needs the 32-bit jvm. But to be clear, whatever CF bit-version you installed, it then needs to use the same bit-level of JVM. And you need to use the same bit-level to run the installer, or this error will happen.

In this case, the 32-bit JVM was the "public jre", so that when the java command was run at the command line (not specifying the folder the java executable should be found in, and assuming you're not running from within a folder with its own java executable), it was this 32-bit version of Java which ran.

And the problem with that is that then the CF updater ran in 32-bit mode, and it implemented files into CF that were now 32-bit versions, and that's why CF then would not start (since its jvm was 64-bit but these 32-bit files within CF were being loaded).

So first, how would you know if the java you see running at the command line IS a 32-bit one? Well, if you ran the command with the "-version" argument, to reports its version info:

java -version

if in the info on the last line shown starts with "Java HotSpot(TM) 64-Bit Server VM", that's a 64-bit one (obviously), but if it just says "Java HotSpot(TM) Server VM", that is a 32-bit one (not as obvious). If it IS a 32-bit one, and your CF (and the JVM it uses) is 64-bit, then you MUST NOT use THAT 32-bit java to run the updater.

(Before I tell you the RIGHT one to run, you want to first uninstall the update you just did, to UNDO those "wrong files" that got implemented. I'll show you how to do that in a moment. But first, let's continue what you SHOULD have done, in case folks reading this have not yet made the mistake, but caught it before they ran the wrong bit-level java command.)

Instead, you want to point to a 64-bit JVM. You could point at the one in CF's JRE/bin folder, or if you had changed CF to use another JVM, you could point to that one. If it was installed in a folder like C:\Program Files\Java\jdk1.8.0_144, then you could run the Java within THAT folder with this command (note the use of quotes, because "program files" has a space in its name):

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -version

and you'd also use it to then run the update, using the -jar command and pointing to the hotfix jar, as discussed in the previous section. One variant could be:

"C:\Program Files\Java\jdk1.8.0_144\bin\java" -jar C:\ColdFusion2016\cfusion\hf-updates\hotfix-002-299200.jar

And what if you have run the installer (with the 32-bit java) before seeing this post, and CF is not starting? Well, you would want to uninstall the update you just applied (and get those 32-bit java files, among other updated files, removed). To do that, go to the "uninstall" directory under the folder for the update you just applied (within cfusion\hf-updates), and use that same 32-bit java to uninstall the update:

java -jar uninstaller.jar

After that uninstall runs (and you check the log, as discussed above, to make sure there were no errors), CF will revert back to whatever update level you were before applying that last update. And you will find that CF DOES now start. But now, start things over. Run the update you were wanting to apply in the first place (using the java -jar pointing to the update jar, as discussed in the previous section above), but this time be SURE to run the 64-bit Java command as just discussed. Then check the update log, and you should find that CF starts. Yay!

Another gotcha to beware, when CF is started by the manual installer

Whether you have the last problem or not, there's one other potential gotcha when you use the manual command-line installer. The good news is that it's easily resolved. I've mentioned that after running the installer, the updater will try to start CF. That's a good thing. But watch out.

You want to watch for what user CF is "running as" after the command-line installer starts it. (You can see the user name which is running any process in Task Manager in Windows or via top in Linux.)

The problem is that I have found sometimes while the manual update process will properly start CF as service (in Windows or Linux), at other times I have seen it start CF WITHOUT running it as a service and worse, running as the user who ran the update.

On the surface, this may not seem a problem. CF is "running" at least, but this could be a real problem if the CF service (which it should have run as) is configured to run as some other user: whether a specific user (best for security), or the default of "local system" (Windows) or root (Linux). The issue is that the user YOU'RE logged in with (to do the update) may be none of these, and if CF runs under THAT user, there are some CFML operations which may not work because of that (you may not have proper permissions).

So if you don't see the service running, or you see the CF task running but not as the user who it would have been running as if started as the service, then kill the process (in Windows, go to Task Manager, find the coldfusion.exe, and kill it), and then start the service yourself (in Services, in Windows, for instance), just like you normally would. All should then be well.

Another facet of how this problem can bite you is that you may not notice this has happened (the manual updater started the CF process, but NOT the CF service), and you may then go to try to start the CF service, only to have it report that it cannot be started. In the situation above, it's simply because it's already running, as a process. But you may be in a bit of panic, if any of the many issues above may have happened, and you may presume "something must be wrong". You may not even think to simply check and see that, for instance, the CF Admin would at least open (as may your web site, likely). So in that state of mind you may think you have to restart the box--when all you needed to do, again is to have stopped the one that was started by the updater, and THEN start the service.

Is CF running now after the update? Great!

So with all these possible issues resolved, if CF now starts (as the right user, see above), and you can access your admin, and it shows that the update has indeed applied, then you're good to go, and glad to have helped.

(As for how to check that an update has applied, other than using the log discussed above, you can also check it in the "updates" page of the admin, of course, on its "installed updates" tab. Perhaps better would be to look at the "system info" page, via the "i" in the top right corner of the admin, or the "settings summary" page listed on the left menu in the admin, which both report the CF and jvm version that CF is running.)

Again, on the surface, all of the above is quite simple once you understand it (finding if there are errors in the logs, stopping CF and running the update manually). It might be literally a 5-minute job when you know what you're doing.

But for folks who don't know, they can be down for hours or even days, which is tragic. I've even seen people go so far as to try (or be told to) uninstall/reinstall CF in the hopes of fixing such problems...and all it may have taken is stopping CF before applying the update!

See below for more on getting help if you do still struggle with some problem.

One other "problem" and its solution: how to download the CF updates manually

Before concluding this post, it may be that the "problem" someone has in applying these updates is very different: they may find that they can't even USE the CF Admin feature to download the update jars, because their server doesn't have internet access (for security reasons).

The good news is that there is indeed a solution to that, but again it seems many don't know about it (I don't see it generally offered by the community when people complain of this problem online).

Adobe has pages for each release listing the available jars for CF10, 11, and 2016, such as https://helpx.adobe.com/coldfusion/kb/coldfusion-2016-updates.html. (You can change that to 10, 11, or 2018 to get the jars for those.)

You would just download the desired jar file from there, and proceed with the manual command-line update process as described above. (Do beware that sometimes some versions of Windows or browsers will mistakenly convert a jar file into a zip when you downloaded it. If that happens, just rename the extension back to "jar" before running the "java -jar" command above.)

Still having problems? Reach out for remote help

If you're still having problems getting an update applied, you can certainly add a comment here and I'll try to get back to it, but perhaps better would be just to reach out for paid assistance. Sorry if this seems like a sales pitch, but I share the above based on my experience helping people. This sort of CF server troubleshooting is all I do all day every day, for hundreds of clients a year and over a thousand the past 10 years.

And some people would really just rather have (or would fix problems query by having) someone help ensure all this is considered and done right in 15-30 minutes rather than struggle on their own to consider all the issues above.

I can nearly always work remotely (via shared desktop solutions you may favor like gotomeeting, webex, or my preference join.me, among others), so you don't need to "give me remote access" (like RDP or ssh, which require you give me or create new credentials, or may require opening a firewall hole, or require VPN access). With a shared desktop solution, none of those are necessary, and we'll look into the problem together (I'll guide you to the problem and solution).

And we may not need very long at all: I can solve many problems in less than an hour. You can find more on my rates, approach, satisfaction guarantee, client references, and more at that consulting/support page on my site.

For some problems, there is just only so much one can reasonably anticipate in advance--even considering the ins and outs as I do in blog posts, presentations, videos, and more. Often there are just too many variables to consider and fully resolve a given problem generically (though I do try, as seen above).

In cases where the info I or others share doesn't suffice, or if you have some other knotty problem, don't suffer it for long. I'd even go so far as to say don't spend more than 15 minutes trying to google for a solution (where you may be led down all sorts of rabbit holes from well-meaning people, or perhaps dated info), if instead you can lean on someone who knows what they're doing and can get you to your solution--targeted to your specific problem, your environment, and your skill level--perhaps without much more time. Especially when your satisfaction us guaranteed!

There's just no substitute for the calm, experienced hand of someone who's "been there, done that", when it comes to problems like applying updates as above, or if you update your JVM and find CF won't start, or challenges like migrating to new CF releases, or updating/tuning the web server connector in CF10 and above, and so on.

If these problems were simple to solve, you'd find the answer in a tweet. Because they are not (lots of moving parts, common misconceptions), many struggle, perhaps finding only info that someone felt was "the least necessary to say", and leaving you to ferret out the details, or worse the solution to problems when things go wrong and they "left out that detail".

Whether in public resources or direct consulting, I not only want to help you solve your problem but also help you understand it: what happened, why it happened, and how to perhaps prevent it in the future!

Let me know what you think about the problems and solutions above.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
The training part where you explain whilst connected via remote desktop is an absolute winner!
# Posted By Ken | 10/6/16 1:41 AM
I didn't know about the update log, thanks Charlie.

It wasn't hard to search through the log file for the 1 warning that I had showing up: ag -i "Status: [^S]" hf-11-00012.log

Just look for a "Status:" message that doesn't start for "S" (as in SUCCESSFUL)

The Warning was trying to copy or move the entire cf root folder - I can't see why the installer would want to do this? Does the updater back up the entire cf directory as it updates?

Move Folder: Destination: /opt/coldfusion11/cfusion
Status: WARNING
Additional Notes: WARNING - There was a problem copying /opt/coldfusion11/cfusion
Hi, Peter. No, the updater does not try to "back up the entire cf directory". :-) I suspect what you're seeing in that message is just an overly simplistic warning. The updater DOES indeed backup files, but only the individual ones that are to be updated.

But as I said in the blog post, the most common reason that it can't do THAT (or whatever it wants to do, especially modifying files) is that the CF instance (and processes or services related to CF) did not come down when the update told them to. (Or if you stopped CF yourself, and tried to apply the update manually, you did not bring down all the processes/services related to CF.)

So as I discuss in the post, you have 2 choices: try the automated update again, or try a manual update.

And if you are going to try the automated update process, I recommend you first restart CF (in case doing that would make it restart faster when the updater would do it), and then before trying the automated installer again, go ahead and stop the related CF processes/services yourself. Then the updater need not bother (but of course you can't stop CF itself, as the automated updater runs from the Admin!)

Or again, finally, you can just go ahead and stop CF and all the related processes/services, and do the CF installer manually, from the command line, as I discuss above.

For anyone reading what I'm writing here and feeling a bit lost, please reread the post above.

And Peter, if with that explanation (and your own rereading of the post) you are somehow still doubting what I say (that CF is NOT trying to "backup the entire cf directory"), please do write back.
First off, thank you Charlie for all of your great blogs! They are extremely helpful!

I have a question regarding manually installing the update. Would I use the java.exe file that is located within the Coldfusion directory, or would it be the java.exe file that is located within the JRE version that Coldfusion is currently running on? For example, if Coldfusion 11 is running on Java 8, should I be using that java.exe to execute the .jar file?

The reason I ask is because I tried to run the updater via CFADMIN, and it failed. Looking through the update logs, I see ALOT of the following error:

Jump To: Next Validate_CF_Directory -- Prev: NO JUMP
Status: ERROR
Additional Notes: ERROR - java.lang.StackOverflowError


I also got a few:

com.adobe.ia.customrule.DocRootValidate
Status: ERROR
Additional Notes: ERROR - Unexpected Fatal Error in Class: com.adobe.ia.customrule.DocRootValidate.install()

Thanks!
# Posted By Robert | 6/18/18 6:57 PM
Robert, first, thanks for the kind regards. Next, as for your challenge, well, you do indeed have choices.

As you may have noticed, I left the details of the discussion of running Java to that Adobe blog post I pointed to, and perhaps you saw that it has you point to the Java that is implemented inside of CF (in CF's JRE folder). (The blog post has an error where slashes are missing, but most should be able to see past that.)

One problem with their proposing you do that is that technically I would argue you should be using the same version of Java that CF is itself using. And as you note, you could have changed CF to use a DIFFERENT java version than the one in the CF JRE folder (as set in the CF Admin Java & JVM page, mirrored as the java.home in the jvm.config file).

So I would propose that you should point to THAT one (wherever it is) as the path for the java command. (And as their blog post notes, do be sure to run that command line "as admin" if on Windows.)

As for your errors, those are indeed odd. To be clear, I would expect if you ran the update from the CF Admin that CF WOULD itself be using the JVM that it points to (in the CF Admin "java & jvm" page).

So I would be curious if you would somehow NOT experience those same errors if you ran it yourself.

Definitely an odd one. Perhaps there's more to your errors than meets the eye. For instance, perhaps there are errors in the log that precede those you refer to, and they could point to some other problem. Or as I hint at above, if you were to restart CF and THEN try the update from the Admin, might that work without error? WOrth a shot before trying it from the cmd line.

Anyway, will love to hear how things sort out for you. And of course if you may prefer direct help, I can offer that. See the consulting page for my approach, rates, satisfaction guarantee, and more. Either way, I hope you'll update folks here on how things go.
Thank you Charlie.

The log file starts off with a bunch of "custom action" that are all successful. When it gets to "install action", that is where the errors start. Nothing very clear from the messages.

I tried installing from the CF Admin twice (CF11 Update 14). When the first attempt failed, I rebooted the server to start with a clean version, and it failed again. What is odd, is that I have Coldfusion installed on my E:/ drive, and Java on my C:/. I noticed that a new "Coldfusion11" folder was added to my C:/ drive when I ran the install, and that is where all the update information has been stored. I have never had this happen. The only change I have made recently was updating the Java to version 8. Perhaps something is wonky between CF and the fact that the Java is on another drive.

I will try the manual update next week and will get back on how that went.
# Posted By Robert | 6/20/18 12:59 PM
Well, until you get to try that, I have a couple of thoughts:

- So had you run the command line "as admin", as I mentioned? You don't confirm it (which is ok), but since you say that a cf11 folder was unexpectedly created on the C drive, I thought I'd ask. I've seen that happen in the past but never pursued when/why it had.

- Since that is referring to your running the update with the Java on C, what happens if you try it with the Java within CF (on your E drive)? Your first message referred only to the errors as being from when you ran the update via the CF Admin. I'll be curious to hear what happens if you try the update using the java within CF. I suppose that's what you'll be trying next week?

- If that does work, it could be interesting then if you may install Java onto your E drive (along with CF) and if you run the update again using THAT. (You could technically uninstall the update, but you don't need to. The second running of the update would just basically "do it again" with no harm for being a duplicate, at least in my experience.)

We'll see how things go for you. :-)
Thanks Charlie. Apologies if I was not clear. I have only tried to apply the update via the CF Admin. I have not yet tried doing it manually via command line. As I got errors the 2 times I tried, I decided to hold off before doing anything else. I cannot risk any downtime this week with something going wrong, so will try next week and will let you know. I appreciate all your suggestions/thoughts... ;)
# Posted By Robert | 6/20/18 2:41 PM
I am experiencing the same issue after applying ColdFusion 11 Update 15 were the ColdFusion 11 ODBC Server no longer starts. I'm running on Windows Server 2012 R2.
# Posted By Carlton Ramsey | 9/18/18 7:27 AM
Carlton, there are indeed some others reporting the same (on Windows Server), though I had no problem with the update (on Windows 10). Here's good news and better news. First, see the Adobe CF forum thread here, where the issue's discussed in detail:

https://forums.adobe...

And see the comments today and yesterday, where I identified some issues regarding certain file processing in the update.

If you look in your ColdFusion11\cfusion\db\slserver54\bin\, is there any file of the pattern msvcr*.dll? If not, then it's looking like a workaround (until Adobe perhaps issues a new update) may be to copy the file of that pattern from the update back folder ( \ColdFusion11\cfusion\hf-updates\hf-11-00015\backup\db\sqlserver54\bin) to that folder above. Then try to start the CF ODBC services.

Let me know if that works for you.
Charlie, it has been a while, but I wanted to update you on my issue.

Running the manual installer worked for me. These were the instructions that I received from Adobe.

Please stop the ColdFusion services.

1) Download the hotfix from: https://cfdownload.a...
2) Install JDK 7u80 or JDK 8u121 or higher. Change the JVM path in jvm.config file to point it to Java(For example: java.home= C:\Program Files\Java\jre1.8.0_121)
3) Copy the above hotfix to the java folder- C:\Program files\Java\jre1.8.0_121\bin
3) Launch the command prompt as Run as administrator & navigate to this location C:\Program files\Java\jre1.8.0_121\bin
4) Use command "java -jar hotfix_014.jar" & follow the on screen instructions. Restart the CF service and check.
# Posted By Robert | 9/25/18 1:31 PM
Hi, Robert. Yep, those are indeed the sort of steps one could/would follow to manually apply the update, as I discussed above in the comments and blog post.

Glad it got you going.
I had the issue of ODBC Server not wanting to start after running CF2016 hotfix 8 and thought I'd share what worked for me (btw, I followed the manual install advice here and the install log said everything was successful).

The windows application error stated "Faulting module path: MSVCR100.dll" so I searched the entire server and no file by that name existed. I found the file on a development machine (in Windows\system32) and copied it over to the windows system 32 folder on the other server, and … presto! CF ODBC Server started right up.

Hope this helps someone! I've received a lot of good advice from Charlie and the others here.
# Posted By Scott | 2/14/19 12:03 PM
Thanks, Scott. This is indeed a problem some are experiencing, and though the solution had been posted on various Adobe blog posts and discussion threads, I had not thought to add it as a comment here. I appreciate your doing it.

I would hope Adobe will fix it, and/or we find out what may be unique to cause some to experience it and not others.
Thanks Charlie for such a valuable resource for the CF community.

"Another gotcha to beware, when CF is started by the manual installer" covered my last two update issues.

The manual updater for my installation runs in a CMD window, and when it is done, it restarts CF as a process as the same user I launched the updater with. In my case, the administrator!

The CF add-on service starts up, but the CF Application service does not--and if I try, it complains.

As you pointed out--I just looked for the Coldfusion process in the task manager. I stopped the task. I then manually could restart the CF Application service.
Thanks, Frank. And yep, that's quite a doozy for the unsuspecting. So easy to read it as being "cf can't start", when indeed it has. :-( I can only hope that folks might see my post before reinstalling CF in panic.

And I hope someday Adobe can fix that.
Back to Scott's comment about the issue with CF's ODBC services (after recent CF updates), I will add that a few days later I posted a new blog post addressing that, on the CF portal:

https://coldfusion.a...
I should add here that last month I created a related post on the Adobe CF portal, which focuses on the key point here of looking in the CF update log, when you have trouble after applying CF updates:

https://coldfusion.a...

Hope it may help readers, here as well as there.
Hi Charlie -- I'd be grateful if you might want to comment on this?

https://stackoverflo...

Here or on SO, I'll take whatever I can get! :) Thanks.
# Posted By Sung | 8/5/19 8:40 PM
Sung, have you seen my reply there?
Is it safe to remove the contents of the hf-updates folder, if all hotfixes/updates have been applied successfully? On CF2016 this folder has grown to over 3GB in size, and it would be nice to reclaim that space. I hate it when software companies and devs have zero respect for our finite and sometimes expensive resources... real pet peeve. If CF could just keep track of what updates we've applied and then give the option to remove the update resources, that would be a real nice-to-have.
# Posted By Franc Amour | 12/18/19 1:11 PM
Well, no. I would not think it "safe" (or wise) to remove the folder entirely. But I can offer thoughts on how to decide what WITHIN the folder may be safe to remove/move (on a per-completed-update basis), and when.

While I appreciate your concern that it seems disrespectful for them to just let them pile up there and "not remove them for you", I can see why they'd think that risky to do for you. The files in there are useful for a variety of things, and even the update folder for "a couple of updates ago" may prove valuable, as I will elaborate.

And I realize you're saying that "all updates have been applied successfully", but even so I'll share a few reasons why that may not be as clear as it seems.

First, I have helped many people who found out days or weeks after applying an update that there WAS in fact an error in the update. They didn't know, because CF came up, and they could run their app and the CF Admin, but down the road something showed up as failing, and we traced it to an error in the update. If they had simply deleted the whole hf-updates (or even that for a past "successful update"), we could not have looked at the log (the install log in the folder for each update) to know that this a missed failure in the update was the real problem.

Second, as you may know there was a recent problem in the Sept updates where the update proved over time to have problems. It wasn't immediately obvious, as it affected only certain situations. If one had deleted the update folder for the previous "successful" update/s, they would not have been able to do the uninstall back to that. (The uninstall uses that.)

So that at least argues for keeping the LAST update folder in place.

If you have more than one past update, and you decide after some period of time (I'd think months) that updates prior to that are no longer needed, you could delete those folders. (Or again perhaps better, move them to some archive location. You could move them back in if you needed to do an uninstall.)

As for the .jar file for each update, it's used to run that update (which one may choose to do after an uninstall), and it grows and grows with each update, as they are cumulative. But that can be downloaded from Adobe, so it's perhaps the safest thing of all to "remove". (The updates.xml file gets updates also when an update is downloaded.)

There is also a .properties file for each update applied, but it's tiny.

Still, if you wanted to, you could consider all three for each update as a group: the update folder, the .jar file, and .properties file. And once you really no longer "need" it, you could remove them as a group (or I'd argue, move them, to be safe).

(One might propose that you could compress those 3 as a group, but I found that the space savings on compression was only about a 20% reduction. This was the same if compressing just the update folder, and/or also the .jar file.)

So there you have it: again I'd say don't remove the entire hf-updates folder (as you proposed), but you could consider carefully which of the other items within it can be removed, and I'd recommend you do it as a group (per update).

And all that said, I could see value in Adobe at least adding an interface offering folks the ability to delete or move the group of related files/folders for a given update beyond the last one. You could make a feature request for that at tracker.adobe.com, pointing to your comment here, so interested folks can see the subsequent discussion. The link to your comment is https://www.carehart... (I added this paragraph as an update to my comment just after initially posting it, as I forgot I had meant to mention it.)

I'd look forward to your thoughts, or those of anyone else. This would make a good blog post, which I hope to turn this into.
Yes, I specifically meant (and wrote) that I was interested in removal of the contents of the folder. Relocation would be included in that, instead of outright deletion, if desired.

From what you wrote, it sounds like those files/directories can be safely deleted or relocated without breaking anything currently running in production (including reboot survival), with the recommendation being to relocate those contents in the event that a rollback is required.
# Posted By Franc Amour | 12/20/19 8:50 AM
OK. You said "remove", and I went with it. I sometimes reading between the lines of what's said (or not said), and answer based on my past experience helping people with such challenges. I thought the additional elaboration may benefit some readers, but I realize some prefer brevity.

Indeed, if you had asked originally whether removing the contents would affect currently running production/restarts, I would have said no (though to be clear I would have still offered the rest also, for the sake of others).

So to your bottom line conclusion, I do concur.
Just wanted to clarify (further, probably beating a dead horse, lol) that "remove contents" was my intention, not to remove the folder itself which i would never propose as it's obviously a part of how CF server itself does things. And by "remove", I had "delete or migrate elsewhere", which wasn't as clear.

And by all means, the full exploration you ventured is as much appreciated as the "short version" as I know it will help others!! =)

Thanks for your ongoing attention to detail and accuracy and for your continued contributions to the CF community. It feels like an ever-shrinking island out here sometimes.
# Posted By Franc Amour | 12/20/19 2:35 PM
Understood on the clarification, and thanks for the kind regards. It's sincerely appreciated (because quite often people do "take" without expressing any gratitude).

As for the CF community seeming a shrinking island, I realize it can feel that way--especially listening to what some say.

FWIW, there are many different places where you will find vibrant CF communities, from the CFML Slack group, to the Facebook CF Programmers group, to the CF Portal (coldfusion.adobe.com), to the CF forums (community.adobe.com), to of course the community surrounding Ortus products (which I realize has a mix of CF and Lucee folks), to name just a few. More at my category of such help resources, http://www.cf411.com...

To stretch the analogy, while some may well get the sense from their perspective that CF is an island, I'd say it's more like an archipelago (a group of islands), like Hawaii or the Florida Keys, each with a different vibe. Definitely bigger and more varied than a visit to any one island would suggest. :-)

But I will say that we're getting off-topic (my doing here), and also such discussion can bring out the vigor in some who would be otherwise silent. :-) So let's leave it at that, and wish everyone happy holidays.
I had to run CF 2021 update 6 from the command per instructions from adobe . The updater said it completed but when I tried to log in to CF Admin I received "The administrator module is not installed." I tried to install it using the bat file but just errored I ended up rolling back the snap shot but still need to get update installed and ideas ?
# Posted By Mike Rockey | 4/13/23 7:05 AM
What was the error with the bat? Did you simply need to set the
JAVA_HOME env var?
Hey Charlie, managed to do a critical P1 update myself this time thanks to the above docs - got past two "gotchas" and the update worked fine for once!
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting