I had the privilege of going to one of the Microsoft courses yesterday for "Deploying Windows 2000 Professional", course 1567, and found it to be rather interesting. I have been to a few of these courses in the past, but most of them were information only, leaving the hands-on stuff for us to take the beta home and deal with. I guess they figured there would be too many questions about bugs or something. Anyway, back to the subject at hand, we had the opportunity to run through some of the basic stuff, installation, imaging, etc. The one feature that we also got to demo was the Veritas Windows Installer that they are using to create their .msi files for software distribution.
This product was pretty solid, breaking everything down to the visual, no scripting. So, we ran through an installation of some tiny little program (which I am sure they used because it would cause no problems). Here's where it got strange. As we were taking the post-installation snap shot, we got an error:
I did not have ample time to test why it was that we got this message, but we tried to just "ignore" it and got the same message again, so we were forced to"abort" and try again. The second time we ran through the snap shot, we got no error. While the rest of the group was ready to just say that that was fine, I persisted to ask why the error had come up the first time but not the second. My questions went unanswered as it seemed that the rest of the class was ready to just accept that sometimes things like this just happen (typical). Anyway, we went on and remotely installed it onto another machine and it seemed to go fine, icon was created, we opened the program, it had even picked up a couple of modifications that we had added. Everyone was happy, the world was going as it was supposed to.
So, the class moved on to OS imaging and that was that, but when I went back, I noticed that an error log had been placed on the root of c: of the machine that received the software. Sure enough, it was the same error that I had gotten during the snap shot, but no error had appeared during the install. There would be no way of knowing that anything was wrong with this product until an end-user found out.
Now, I don't know what cim.#ec is responsible for, but you can bet that when it's function fails, users are going to be calling the helpdesk and they are going to be pissed. This, of course, will be blamed on the administrators and you will have to go backtrack and figure out what the problem was.
Error messages, although sometimes very annoying, are there for a reason. I am eager to continue testing with this product and will attempt a re-creation of this issue. As always, I will keep you all up to date.