Need to install LOB app on new PC where vendor is absent

timeshifter

Well-Known Member
Reaction score
2,366
Location
USA
Problem: need to install LOB software on a new PC, but the software vendor of that LOB has closed up shop.

The program is called SwiftLink. Used by appliance stores for point of sale, etc. It's a pretty ancient program. Whenever I had installed it in the past it usually involved a call to the vendor and they'd remote in and do the install which involved running an installer from their latest CD (that was sent monthly, but haven't sent in a long time), then they'd open a command prompt and register a few DLLs or OCX - don't recall exactly.

Within a few weeks we'll be on a new program, but for now there's a new employee and he needs the program. Business owner has been bugging me.

I tried cloning an old PC of theirs. Turns out it didn't have the program :(. Also, it got a little sketchy - trust relationship to domain broken, etc.

I'm thinking about cloning an existing PC they have running it, but I'm a little nervous. Since it's on a Windows domain a straight clone with Macrium would likely cause issues. How do I break the association? I think it's called getting a new SID?

If I can safely clone, disassociate and rejoin the domain I think that will work. Is that a good plan? Any other thoughts?
 
I'm thinking about cloning an existing PC they have running it, but I'm a little nervous. Since it's on a Windows domain a straight clone with Macrium would likely cause issues. How do I break the association? I think it's called getting a new SID?
Sysprep is what you're looking for.

I think I'd be tempted to have a go at copying the program over to a new system manually -- that's worked out well for me on a few occasions. Copy all the obvious files over first, then dig through the registry, AppData, ProgramData, etc copying over anything relevant. Then try launching the program. It might not run straight away, but with any luck it'll give some helpful error messages as to what's still missing (and, if it doesn't, try comparing Windows system folders for any extra fils it may have dropped in there). Make a note of everything you copy over in case you do get it to run, for future reference. It might even be possible to create an installer script to automate the entire process in future.
 
Sysprep is what you're looking for.
Starting to be clearer. So I could clone a working PC using Macrium. Boot the new image in the new PC then Sysprep it. Next time the machine boots I'll go through OOBE (I think). Make sure it has a unique name. Connect it to the network then join domain.

Sound pretty safe / reliable?
 
So I could clone a working PC using Macrium. Boot the new image in the new PC then Sysprep it. Next time the machine boots I'll go through OOBE (I think). Make sure it has a unique name. Connect it to the network then join domain.
Exactly.

Alternatively, boot a cloned drive in the original machine and sysprep that instead. Just don't sysprep the original! :)
 
Having some trouble. Booted the cloned drive in the new machine and sysprep with generalize wouldn't work. Of course I didn't write the error down, because I was going to try something else, and while I'm waiting for that something else to process I'm posting here. The error talked about not matching something in the panther directory, some kind of setup log I think.

I tried booting the clone in the original machine but that didn't matter. Of course that clone had been already booted in new machine.

Right now I'm making a new clone to boot in the original machine and see if I can sysprep that.
 
Right now I'm making a new clone to boot in the original machine and see if I can sysprep that.
That would be my suggestion. Ideally Sysprep needs to be done before moving the installation to new hardware but sometimes it'll work after the event. Probably depends on how dissimilar the systems are.
 
Having trouble making a new clone to sysprep. Is there another way to get this to work?

I don't really need the machine to join the domain.
 
I don't recall ever seeing that error before, but then most of the Syspreps I've done were on new systems. Looks like there might be a number of possible causes:

Might be quicker/simpler to try manually transferring the software over -- Copy what you can find and see if it runs.
 
I agree. Sysprep on the old machine. I'd image the drive to another, boot from that on the old machine, make sure everything is hunky dory, then sysprep, then image that to a different known good hardrive. Install on new hardware and go from there. During the downtime this year I spent some time working on WDS and sysprep. Never had a problem sysprepping and existing HD on the original machine following the above.
 
Fun story...

So I tried to hack it together and make the program run on his existing machine. First error was about a missing dll named something like F5DDAPI.DLL. Found that file in a folder on working machine in c:\program files (x86)\common files\fujitsu\cobol. I moved that folder over but it didn't help. Later I noticed in Programs and Features an installed program called RuntimesV10 by Fujitsu Ltd. Not knowing where I could find that installer I gave up on that idea. NOTE: this program uses COBOL? Told you it was old!

Anyway, I proceeded with my dirty clone. Removed it from the domain. Changed the name. Booted and mapped the correct network drive. Note I did not join domain, just manually entered credentials for the share.

IT WORKS!!!
 
I used to manually copy old apps. It takes time and patience but it generally does work.

I forget the name of the tools, but you need a tool to monitor the app for DLL calls and registry points. There are both apps that can monitor and apps that scan an exe.

Now, sometimes a DLL needs to be registered, other times it can be copied to the place where the main exe will be, other times there will be a random folder that seems to be hard coded that you have to recreate.

I enjoy manually transfer these apps, it's a good brain exercise!
 
Fun story...

So I tried to hack it together and make the program run on his existing machine. First error was about a missing dll named something like F5DDAPI.DLL. Found that file in a folder on working machine in c:\program files (x86)\common files\fujitsu\cobol. I moved that folder over but it didn't help. Later I noticed in Programs and Features an installed program called RuntimesV10 by Fujitsu Ltd. Not knowing where I could find that installer I gave up on that idea. NOTE: this program uses COBOL? Told you it was old!

Anyway, I proceeded with my dirty clone. Removed it from the domain. Changed the name. Booted and mapped the correct network drive. Note I did not join domain, just manually entered credentials for the share.

IT WORKS!!!
Probably needed to regsvr32 that bad boy
 
Back
Top