Minor AD/SSO issues when using .MSI install

After finally getting SSO working with AD I’'m trying to recreate the client side steps in advance of rolling it out. I completely removed spark, the spark folders and the spark profile folder. I then removed the krb5.ini file and registry key needed to get it working.

I re-installed the MSI and confrmed SSO wasn’‘t working, added the reg key and then the ini file… and it still wasn’'t working. Upon looking at the client log, it was looking in C:\WINNT for the .ini file instead of c:\windows.

Went through the cycle again but this time installed using the .exe and the SSO worked first time. So it would seem the MSI install is doing something strange.

This is on an XP SP2 client.

I have found that the msi installer has various different issues, that do not appear to be present when I used the exe installer. I there for used the exe installer to repackage into a msi that included the registry file and ini file. I also created a batch file to run the msi as and admin to install as the local user so I do not have to push a 35MB installer via AD around the country. Everything worked fine then. I also created an exe installer for the default settings for the currently running user. This is needed for profiles that already exist on a machine. It does not require admin to install. In short though the msi installer from ignite realtime is faulty to varing degrees.

Are you repeating this on the same exact system? The difference between C:\WINDOWS and C:\WINNT is installation specific. I think there is some variable you can use (%WINDIR% ??) that should make it consistent.

yes, exact same system and it’'s repeatable for me. Uninstall .exe, install .msi, SSO fails.

Well, something changed. Java looks for %WINDIR%\krb5.ini . %WINDIR% should not be changing- at least nothing Spark does has the ability to change that.

I checked that and %WINDIR% stays consistent at C:\WINDOWS. However the error only appears following an MSI install where it’'s looking for C:\WINNT\krb5.ini which is NOT what %WINDIR% is set to.

Strange huh.