Jeremy Sturgill

Last comment - as we found this interesting. Although we have the Kerberos tickets set up for 10 hours - it "appears" everyone gets the same End Time - until hat 10 hour chunk has finished. This means - the later in the day you log in - the less and less of the 10 hours you get. It took a bit to figure this out . We have several users starting at 4:30 AM....but most users start at 7:00 AM. But - they ALL got the 2:30 PM Kerberos end time. I initially thought they were only getting 75% of the 10 hours - but- this does not appear to be the case. They just seem to get the same end time -as whoever logged in first for the day. I naively assumed- each person would get a full 10 hours. That does not seem to be the case. If we can figure out how each person gets the full 10 hours - my problem goes away. If we can figure out how the renewals can be happy - even if the IBI_SESSION_TIMEOUT is pushed past the Kerberos end time - I think we'll be good.

Thank you Patrick. A 10 hour lifetime - and 7 day renew are default Kerberos settings in the windows world. That was indeed the doc we followed for our initial setup. We are still struggling with renews though. Though troubleshooting - it's clear - if people are inactive - and get signed out - when they come back after the Kerberos timeout - they are properly re-authed - and get back into webFOCUS. This is good. However - if people are working all day - the IBI_SESSION_TIMEOUT is pushed PAST the Kerberos end time. When this happens - people are unable to re-auth. People see "Reporting Server Error - No Single Sign On ticket" error. They are then hosed until one of the following actions happens: Wait for web session to expire. Clear Cache Clear the webFOCUS specific cookie Ideally - we'll be able to find some setting that help it to renew - o r- we can reduce the IBI_SESSION_TIMEOUT - but this feels like it just narrows the window when bad things happen - and isn't really a fix.

We recently converted webFOCUS over to using Kerberos. Overall, this is working well. No on needs to supply credentials. We can use Klist - and see a Kerberos ticket. All works well. For about 7 hours. For the life of me - we can't figure out why it seems the Kerberos ticket is not auto-renewing. Around the 7 hour mark (of our 10 hour krb5.ini lifetime - (speculating here) ) - people start seeing "No Single Sign on ticket". And - they are dead in the water. Not everyone gets this the same time - or - it's maybe more accurate to say - not everyone notices this as the same time. They are able to clear cache - or - more specifically -they can just delete the single webFOCUS cookie -and they are back in business. We do have a case open with Tibco - but - as of yet - we don't have a good handle on "why" not everyone is getting the refreshed session. I'm wondering if anyone here has Kerberos working properly - and maybe has some suggestions? The parts of the krb5.ini that we think should be honored - but - doesn't seem to match our expectations: [libdefaults] ticket_lifetime = 36000 renew_lifetime = 7d

Ty. We have tentative plans to dump prod - and Dev resources - and look for discrepancies. Should be reasonably trivial to generate a report of resources in prod - that are not in dev. This will be our plan of attack if we dont find some other option.

Ty. We tried GIT but ran into errors. We didnt think it was quite ready for prime time. We opted for TFS - which doesnt seem as sophisticated. I will look at the log and see we can leverage that.

We have webFOCUS Dev, Test and Prod environments. On occasion - we retire a *.fex or *.htm from dev - and delete it from Dev. The Change Management, as far as I can tell, does not clean up Test and prod - if we delete a resource from Dev. Is there some standard way to address leftover resources in Prod - that are no longer in Dev We could Nuke all prod resource - the re-migrate all of our Change Management packages. But this feels kind of extreme. Im hoping theres a smarter way to deal wit these leftovers.

Thanks. I do have a case open. Im sure, eventually, well get it figured out.

When we upgraded to 8207 - the Resource Analyzer was adding enough overhead that we disabled it. That issue was fixed when we upgraded to 8207.22 - so we re-enabled Resource Analyzer. Sadly - all of the RMARCHIVE jobs are now stuck in Queuing. Wondering if you have a suggestion on this. queuingIssue.jpg34781692 556 KB