Clock-Windback detection with an FlexNet Embedded client
SummaryDo you need to separately resolve clock-windback once you've corrected a client system clock?
QuestionIf a client system activates a capability request and then realizes their system clock isn?t correct, after they fix the system clock, the clock-windback detection gives an error. The question is, do they need to reload the license from the server with the new client time settings to avoid this error? Or is windback detection evaluated each time a client attempts to acquire a license? And if the former (which I assume means there?s a flag or something set in the Anchor file?), what?s the process on FNE to fix a clock-windback flag? Or am I completely misunderstanding how this works?
If they set the clock back and then restore the correct time, then the wind back error should clear itself.
If they set the clock forward, performed licensing operation, and then restore the correct time, the error persists until the real time catches up with the time of the last licensing operation performed while the clock was wrong. The way to clear up this error is by applying a new capability response, which resets the clock wind-back anchor even if it is set in the future.
In general, we mostly worrying about moving clock backward to extend the expiration time. Setting clock forward might let someone to access the license before its start date, but does not extend the length of license availability.