All too prevalant I'm afraid... I've seen a supply chain system that uses Oracle as it's database engine, but COBOL for its logic with similar requirements. The command interface was actually a character mode application and required that the supply chain team have server console login access ... They *should* follow the design of having the internal system bits run as a service upon boot before any keyboard login, and then have a client interface ( Web/Java, MMC, etc ) deployed to the desktop that connects over the network back to the server bits... Misery doesn't really love company, but you're not alone in this experience !
Erik Goldoff IT Consultant Systems, Networks, & Security ' Security is an ongoing process, not a one time event ! ' _____ From: Mayo, Bill [mailto:[email protected]] Sent: Thursday, January 21, 2010 5:50 PM To: NT System Admin Issues Subject: RE: Reality check I have myself used that software in the past for that purpose. Because of the way this software works (counters, cancel buttons, dialogs when there is a problem, etc), I don't think it would work. Beyond that, this vendor does a lot of "hands on" support, and they would never be able to handle it. So, if there were a problem at 3:00 AM on Saturday and the system administrator contacted their support, they would take one look and immediately blame our environment. I do believe that is a good recommendation in general, though. Bill Mayo _____ From: Sean Martin [mailto:[email protected]] Sent: Thursday, January 21, 2010 5:13 PM To: NT System Admin Issues Subject: Re: Reality check First, I agree with everyone else. Software in today's world shouldn't have that type of dependency. Unfortunately,current versions of today's software probably haven't changed much if they were originally developed many years ago. With that said, have you investigated the possibility of using the resource kit tools (srvany.exe and instrsrv.exe) to run this particular application as a service? I've been able to eliminate your exact scenario on a few servers over the years, but I've also run into many scenarios where it just wouldn't work. In either case, it may be worth a shot. - Sean On Thu, Jan 21, 2010 at 1:02 PM, Mayo, Bill <[email protected]> wrote: Afraid not. The department that uses the software makes the decision about what they use. We can only advise. We previously had a different vendor, and this vendor is actually superior from what I can tell. I don't really deal directly with the vendor for this system, so the only thing I can do is point out the problems to the person that administers the system and to our CIO. The former has been hearing about it all day, and the latter will (he is already aware of some issues we have had when the workstation has had problems). The last time this came up (when I had some involvement with the workstation getting setup), I complained to the on-site tech about it. At that time (about 3 years ago), he said that he agreed and that they were working on converting the processes to services. Guess that didn't happen. Thanks to all for the confirmation that I am not just difficult (at least in this case!). Bill Mayo -----Original Message----- From: Christopher Bodnar [mailto:[email protected]] Sent: Thursday, January 21, 2010 4:23 PM To: NT System Admin Issues Subject: RE: Reality check As long as you are tied to the vendor, they will do whatever they want, which means not fixing the problem. Any possibility of shopping around for another vendor? Chris Bodnar, MCSE Sr. Systems Engineer Infrastructure Service Delivery Distributed Systems Service Delivery - Intel Services Guardian Life Insurance Company of America Email: [email protected] Phone: 610-807-6459 Fax: 610-807-6003 -----Original Message----- From: Mayo, Bill [mailto:[email protected]] Sent: Thursday, January 21, 2010 4:05 PM To: NT System Admin Issues Subject: Reality check I am terribly frustrated with an application vendor who is on-site to add a new module to on of our critical software packages, and I want to confirm it is not just me being difficult. This system already has the requirement that a workstation be logged on with 3 different programs running in the foreground to shuffle data around between modules. To be clear, an account has to be logged into this machine at all times for this system to work properly. They are here now, installing a new server for a new module, and they now have to have it doing the same thing on the server (logged on account, foreground applications running). This is not a minor system (either in size or cost) and the parent company is not tiny (rhymes with "bun hard"). When I say "services" they look at me like I am from Mars. The problems with needing an account logged onto a server at all times seem obvious to me. (The workstation was bad enough.) Am I alone? Bill Mayo ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
