Our firm got an installer from Inprotech that works on some machines but not others. We are on a tight deadline for deploying the installer, and the vendor has not yet been able to help. I'm hoping you can help me gain some insight, or at least help ask the right targeted questions.
I can't figure out why the install works on some machines but not others. I've tried installing using different accounts, checked permissions settings, desktop builds (we're on Windows 7), etc.
The installer should install a new Word add-in that sets up a net.pipe listener to pull information from the web into a template. It installs a service in Windows Services that requires the net.pipe and net.tcp listener adapters to be on. This all appears to go smoothly. However, when I test the connection, on machines that fail I get an error that:
"There was no enpoint listening at net.pipe://localhost/[domain] that could
accept the message...
The pipe endpoint 'net.pipe://localhost/[domain]' could not be found
on your local machine."
I've created some verbose log files of the working and non-working installations. They're thousands of lines, and I'm not having much success finding any significant differences. The one big difference is that the install from the working machines has hundreds of more lines that look something like this:
MSI (s) (E4:90) [16:31:39:832]: Using cached product context:
machine assigned for product: DB26B2D276F00B24EB6668D6B73666F3
MSI (s) (E4:90) [16:31:39:832]: Setting cached product context:
machine assigned for product: DB8788415A2A1FC41A30B26A234F9135
MSI (s) (E4:90) [16:31:39:832]: Using cached product context:
machine assigned for product: DB8788415A2A1FC41A30B26A234F9135
MSI (s) (E4:90) [16:31:39:832]: Setting cached product context:
machine assigned for product: DDA39468D428E8B4DB27C8D5DC5CA217
To be clear, both logs have hundreds of lines like the above. The succesfful install just has hundreds more lines like the above.
I'm not sure what other information would be relevant to the question. The piece of the install that I suspect is failing also references S-1-5-20. I don't know exactly how it's using the reference, but it sets something up on port +:8000.
If anyone has any advice on how to target my troubleshooting, I'd appreciate it.
Your vendor should look at how its net.pipe endpoint URLs are being defined. If they are using base + relative URLs then this problem may occur on any machine which is running other applications which also use the WCF net.pipe transport.
Looking at the service URL in the error message, I would guess that this is exactly what is happening.
They should use absolute URLs when creating the service endpoints, using names designed to guarantee uniqueness. Then this problem cannot occur.