There is a requirement for a password to change between 01:00 and 03:00 on Saturdays and Sundays; however, this does not work consistently.
Which platform setting may be the cause?
There is a requirement for a password to change between 01:00 and 03:00 on Saturdays and Sundays; however, this does not work consistently.
Which platform setting may be the cause?
The issue with the password change not working consistently between 01:00 and 03:00 on Saturdays and Sundays is likely related to the Interval setting for the platform. The Interval determines how often the Central Policy Manager (CPM) checks for necessary actions. If the interval is set to a value greater than 120 minutes, the CPM might miss the 2-hour window for changing the password. This setting must be less than 120 minutes to ensure the password change occurs within the designated timeframe.
After having checked on lab, there's no DaysToRun parameter, only ExecutionDays. So C is not the correct answer as the parameter invoked doesn't exist. D is the right answer.
The interval setting is to control how often the CPM looks for system-initiated CPM work. If it is >120 say 121 - the trigger happens at 01:00, CPM sees the trigger and tries to act at 3:01. It's outside the window, so it can't change the password.
Interval is the number of minutes after which the Central Policy Manager re-reads the list of platforms. ImmediateInterval determines the number of minutes it takes before the first rotation attempt. HeadStartInterval is the number of days before the password expires. DaysToRun doesn't exist. ExecuteDays is the answer. I think is the parameter should appear in the exam and maybe is the parameter the autor meant
good point, but how about: "however, this does not work consistently" apparently it does work but not always..
Maybe. Yes. Because if HeadStartInterval = 0 means the password will be change the same expiration day. If not equal 0, the password can change before Sat or Sun and other weeks/months can fix that desired days... Good observation.
DaystoRun settting does not exists, HeadStartinterval default is 0.. So I think it must be D
Interval - The number of minutes after which the Central Policy Manager re-reads the list of platforms, to handle new platforms or remove deleted ones. So the interval must be less than 120 minutes to make sure that CPM will change password within that 2 hour window.
Different value than 0 for HeadStartInterval will cause : "not work consistently change between 01:00 and 03:00 on Saturdays and Sundays". F.e when set to 1 then password will not be changed on Sundays as it was speed up 1 day. When it comes to Interval setting . https://cyberark.my.site.com/s/article/00002885 "CPM 9.10 and up, when FromHour to ToHour is used, the interval will be used only within the FromHour to ToHour. Outside those hours, the interval will be ignored." So it looks like the interval is different than defualt or current and the only will change the password within the FromHour to ToHour. As well in article that someone has put here : https://cyberark.my.site.com/s/article/00004112
This is a tricky one but I'm inclined to go A. as well, the interval parameter controls how often the CPM looks for system-initiated CPM work. If it is >120 (2hours) and the trigger happens any later than 01:00, the CPM sees the trigger and tries to act at 3:01 or later which is outside the window. https://docs.cyberark.com/PAS/13.2/en/Content/PASREF/Automatic%20Password%20Management%20-%20General.htm?tocpath=Administrator%7CReferences%7CConfigure%20the%20system%20through%20PVWA%7CPlatform%20properties%7CAutomatic%20Password%20Management%7C_____1#:~:text=value%3A%205-,Interval,-The%20number%20of
It's also worth noting that for versions up to v9.10 there was a formula issued by CyberArk to calculate the value of this parameter when used in conjunction with "FromHour" and "ToHour". The rule was (Timeframe of FromHour ToHour in minutes/2)-1=Interval. For example if set from 2 to 4 am, it would be have been (120/2)-1=59. https://cyberark-customers.force.com/s/article/00004112
The most likely cause of the issue is that the DaysToRun setting for the platform is incorrect So the correct answer probably is C or D.