We are big fans of COM+ here, and use it a lot for projects that have desktop and web components. You probably don’t need convincing of its merits, so I’ll hold off on that.We are also big fans of Terminal Services. Many of our clients are going for the Terminal Server option as it allows them to log in from home etc. OK, you don’t need convincing of its merits either.
Sometimes however we get problems combining the two. That is, we have many clients using Terminal Server and we host our COM objects on that same server in Component Services.
Last night a client rang me to say that one of our apps had stopped working. Turns out they had updated Terminal Services on the server and added a new user. The new user wasn’t working at all. The COM object just plain failed to load. I went down the security and authentication path, thinking that the COM+ service might running under an expired account etc. But it wasn’t that.
So then the question becomes: how do you debug COM+ issues over the phone with the client. And most clients don’t have a lot of expertise with COM+ after all (why should they, that’s our job right). So after trying a few things I finally call Scott (he’s our Chief Software Architect) and ask his advice. He dictates a simple vbs script to me which I relay onto the client. It is really simple, just asking them to open notepad and type in the following:
dim o
set o = createobject(“TechSeller.Application”)
msgbox o.versionnoset
o = nothing
You can change the appropriate COM+ name (in this case ours was TechSeller) and you may change the property you display. We have a versionno parameter on our application object.
OK, so the client saves this on the desktop as test.vbs, double-clicks and whammo, a really obscure error comes up. This script is actually pretty helpful, because the error message is a good guide. If it is permissions it will give you a reasonably helpful pointer to the problem. In this case the message was really weird, and looked like the logged in user couldn’t even call COM+ services.
Next step, yep delete the COM+ package and reinstall it. Worked like a charm. Ran the script again and got our version number.
So, what is the problem then? And here’s where it gets a little grey. We’ve found from time to time that Terminal Server has conflicts with COM+, usually when remote users log in under a different name to the user the COM+ package was installed under. COM+ has settings for impersonation which should take care of all this, but sometimes, it gets a little flaky.
To be fair to Terminal Services, when the client had updated Terminal Services it had warned them that some installed app may not work. Perhaps we should have reinstalled the COM+ package and programs as a rule.
I’ll know for next time.
