Tessitura 15 on Windows 10 with Windows authentication

Hi Damien, 

Yes we are windows 10 (ramp) and it's fine. It does interfere with TSTATS list filtering and utilities that need access to drives such as order import utility so ive taken it off some profiles. That disconnected those logins from the database giving the error that you describe but the ramp team sorted that out for us.

Cheers

H

We've been using Windows Authentication for v15 in our Test environment on PCs with Windows 10 without issue. The only time I experienced a problem was after a Live-to-Test copy. It wouldn't let anyone login until I dropped the logins in v15 Security. Good luck getting this sorted out!

Hi Damien,

I'm having the same issue (non-RAMP). Funnily enough, most of us in IT are fine, and it's everyone else having an issue.   I just haven't had time to look into it yet!

Cheers,
Kathleen 

We've been running on Windows 10 clients for a while now, and had very few problems. Just a few things to check, some are remedial, but I figured I better throw them in from our own experience...

Did you put integratedSecurity=true in the master.bat file or the tessitura.ini file on client machines? If you went the client route,  is that line in your tessitura_ini file of your affected Windows 10 machine(s)?

Are your Windows 10 users set up for Windows authentication in the security module?

Do you have the .net framework requisites installed on the client machines?

Hope you can get it sorted out, because the feature is hugely popular here.

Hi Kathleen,

This sounds suspiciously similar to a problem we had during/after our v15 upgrade, though we're a RAMP client, so I'm not sure how much will apply to you.

It happens to us when a user is assigned to a single User Group and that Group isn't set as their default. Go into Security --> Maintain Users --> Groups and make sure all users have a default selected in their associated User Groups.

It used to be that Tess didn't care if a user with access to a single User Group didn't have a default designated (it would just load the single group as their default), but the new Windows Authentication method does. This is also why IT staff are probably not having an issue - they likely belong to multiple User Groups, so a default group has already been designated.

We self host, for what it matters.

Good to note although that's not the issue here as I can login on some machines but not others so that rules the Group config out.

I assume you mean Tessitura_Master.ini file. Yes the correct extra config is in that on the server and all the workstations Tessitura.ini point the Tessitura_Master.ini on the server.

The Windows 7 and Citrix servers use the same configuration.

.Net 4.7.2 is installed so yes the .Net criteria is met.

SOLUTION: machine missing from TX_MACHINE_LOCATION table.

We've been rolling out new equipment with Windows 10.

Unfortunately Tessitura v15 seems to have removed it's helpful error message "No location assigned"

EDIT: the Tessitura Service does log helpful messages about failed logins like the old "No location assigned" message so this log will be your friend for troubleshooting client login issues. For me it's  C:\Tessitura\Logs\TessituraService  which I think is the default location.

Ha, yes, obscuring the reason for the failure has been deemed a security feature. Glad you got it sorted out!

I really hope that is not the case.. 

That's a reasonable enough thing to do with a login dialog.  Is it also changed in the look?

Matthew Hoyt said:

Ha, yes, obscuring the reason for the failure has been deemed a security feature.

Security through obscurity! A joke, I  hope? ;-)

You can look in the client log to find out this is the problem. On the bright side, nobody has to see the "open session" message if there's an ungraceful exit from the machine any more.