[acs] CMIS won't run as user account, runs fine under Admin account

[TheCrust]

Over the summer, we have rebuilt the network at a partner school. They use CMIS Facility.

 

Since the rebuild we have noticed users are struggling to run CMIS Facility in the context of their own user accounts. If I log on to a PC as the domain administrator and start Facility, the application starts fine and I can use it. If the user logged on to the PC as themselves, despite having the same mapped drive letter to the Facility share on the server, and the same permissions on that share as the administrator (I was testing, I know this is not a good idea long-term), the application struggles to start - often flashing up an ODBC connection timeout error message. They can click through this and the application starts, but they can't do simple stuff like backup the database. The backup operation fails with an "unspecified error".

 

I know this will be related to permissions but I am at a loss to explain where. File and share permissions are - as best I can see - correct (aside from when I slackened them off to eliminate them), the SQL setup is - as best I can see - correct, but still a normal PC user can not seem to run this application correctly.

 

Any thoughts? We installed MS SQL 2008 R2 Express Edition to run Facility in as it's a small school and only one or two staff ever need access - but I've done this before without issue even though I'm aware other schools use full-fat SQL Server. The choice of SQL Express edition was a cost-saving measure for this small school.

 

We used to be a Facility school ourselves before moving to SIMS, but this was four years ago and I've all but forgotten the caveats needed to get Facility to do what you want it to so I've probably missed something blindingly obvious - hoping someone can point me in the direction of just what

 

Thanks in advance!

[michael2k6]

Doesn't sound like you're really missing anything. Ensure that the db ports are open in the firewall, that's the most common issue, but if it's connecting at all you'd assume they're correct. Is it just Facility? Or are you only noticing with Facility due to the amount of network throughput? Could it be something like flakey NIC drivers? Try an open ping to the server, or copying a few huge files from / to it as a test to rule out the app / db.

 

Keep us posted.

[TheCrust]

I'm not on here that often and I've been that busy I completely forgot I posted this thread up, but thanks for the thoughts - all appreciated.

 

I have resolved this issue now. In our case it turned out that the configuration of the DSN on the client was at fault.

 

Even though it would work configured to connect over TCP/IP for administrative users, it really wasn't happy connecting that way as a normal user. I discovered that the work-around is to regenerate the DSN but configure it to connect over named pipes.

 

Quite why this was needed on this install escapes me at the moment. Having checked the server, it is configured to allow connections on both named pipes and TCP/IP. There doesn't appear to be any security set on this aspect of the configuration, so anyone with appropriate permission to access the database engine should have been able to do so over either connection type - but still it would baulk at allowing a non-admin Windows user to connect via TCP/IP even if the credentials being used belonged to a valid SQL logon.

 

Setting the DSN to use Named Pipes instead of TCP/IP has resolved this problem for us in this instance.

[michael2k6]

Nice work, that's a new one on me.