Bala_Delli thanks, the feature is helpful but could be improved by allowing a value larger than 7 though. Also depending on how calculations are performed, documentation should be updated so that we can understand the limitations with the offset..
Rick Cillo NBclientmanager
Perhaps the issue with allowing large values might have something to do with when and how the calculation is performed?
Is there a possibility that the calculation is performed only against the current month of the computers current date and is not calculated as an offset for the previous month?
If that is the case ( current date used only ), then once the computer clock rolls to the next month, any offset would then be applied to the current month, and not the previous month.
This would result in unachievable maintenance windows, either in part, or in whole, depending on the offset.
The Maximum offset in this scenario is 30 days, since 1(minimum current day)+30(offset)=31 (max day number in month)
The Minimum offset is zero days ( Fourth Tuesday of February 2023 is a great example, you can only offset 0 days and still be in February ).
If the calculation does work across the boundaries of a month, then 34 seems like a reasonable maximum, because that the maximum value you would need in order to schedule all the up to the day before the next patch Tuesday. However, people may have reasons for higher values, so if the calculation occurs for the previous month as well, then why not 60 days as cbruscato suggested, or 62 days (34+28)? Obviously a number that high is a very terrible idea to allow if the calculation is only based on the current month. But it's a great idea otherwise.
Here is a function with script to calculate patch Tuesday over the next two years ( including current month ).
It also calculates:
The offset between each patch Tuesday
The offset from First Tuesday to the last day the month.
The offset from Second Tuesday to the last day of the month.
The offset from Third Tuesday to the last day of the month.
The offset from Fourth Tuesday to the last day of the month.
function Get-NTuesday($Date,$N) {
#Calculate N Tuesday
[datetime]$StartMonth = ($Date | foreach-object {$_.AddDays(-$_.Day+1).ToString('MM/dd/yyyy')})
while ($StartMonth.DayofWeek -ine 'Tuesday' ) { $StartMonth=$StartMonth.AddDays(1) }
return $StartMonth.AddDays(7*((@{FindNthDay=$(if($null -ne $N){$N}else{2})}).FindNthDay-1))
}
0..23 | ForEach-Object{
$BeginPatchTues = Get-NTuesday (Get-Date).AddMonths($_) -N 2;
$EndPatchTues = Get-NTuesday (Get-Date).AddMonths($_+1) -N 2;
$EndOfMonth = $BeginPatchTues | Foreach-object {[DateTime]::new($_.Year,$_.Month,[DateTime]::DaysInMonth($_.Year, $_.Month))}
[pscustomobject]@{
BeginPatchTues = (get-date $BeginPatchTues -f "MM/dd/yyyy").ToString();
EndOfMonth = (get-date $EndOfMonth -f "MM/dd/yyyy").ToString();
NextPatchTues = (get-date $EndPatchTues -f "MM/dd/yyyy").ToString();
NextPatchTuesOffset = ($EndPatchTues - $BeginPatchTues).Days;
EndMonthOffset1st = ($EndOfMonth - $BeginPatchTues).Days+7;
EndMonthOffset2nd = ($EndOfMonth - $BeginPatchTues).Days;
EndMonthOffset3rd = ($EndOfMonth - $BeginPatchTues).Days-7;
EndMonthOffset4th = ($EndOfMonth - $BeginPatchTues).Days-14;
}
} | Format-Table -AutoSize
Results in:
BeginPatchTues EndOfMonth NextPatchTues NextPatchTuesOffset EndMonthOffset1st EndMonthOffset2nd EndMonthOffset3rd EndMonthOffset4th
-------------- ---------- ------------- ------------------- ----------------- ----------------- ----------------- -----------------
02/14/2023 02/28/2023 03/14/2023 28 21 14 7 0
03/14/2023 03/31/2023 04/11/2023 28 24 17 10 3
04/11/2023 04/30/2023 05/09/2023 28 26 19 12 5
05/09/2023 05/31/2023 06/13/2023 35 29 22 15 8
06/13/2023 06/30/2023 07/11/2023 28 24 17 10 3
07/11/2023 07/31/2023 08/08/2023 28 27 20 13 6
08/08/2023 08/31/2023 09/12/2023 35 30 23 16 9
09/12/2023 09/30/2023 10/10/2023 28 25 18 11 4
10/10/2023 10/31/2023 11/14/2023 35 28 21 14 7
11/14/2023 11/30/2023 12/12/2023 28 23 16 9 2
12/12/2023 12/31/2023 01/09/2024 28 26 19 12 5
01/09/2024 01/31/2024 02/13/2024 35 29 22 15 8
02/13/2024 02/29/2024 03/12/2024 28 23 16 9 2
03/12/2024 03/31/2024 04/09/2024 28 26 19 12 5
04/09/2024 04/30/2024 05/14/2024 35 28 21 14 7
05/14/2024 05/31/2024 06/11/2024 28 24 17 10 3
06/11/2024 06/30/2024 07/09/2024 28 26 19 12 5
07/09/2024 07/31/2024 08/13/2024 35 29 22 15 8
08/13/2024 08/31/2024 09/10/2024 28 25 18 11 4
09/10/2024 09/30/2024 10/08/2024 28 27 20 13 6
10/08/2024 10/31/2024 11/12/2024 35 30 23 16 9
11/12/2024 11/30/2024 12/10/2024 28 25 18 11 4
12/10/2024 12/31/2024 01/14/2025 35 28 21 14 7
01/14/2025 01/31/2025 02/11/2025 28 24 17 10 3
Notice the presence of 0 through 9 in the EndMonthOffset4th Column, and presence of 35 (inclusive of "next") in the NextPatchTuesday Column
Any way you look at it, 4 and 7 are both too small to allow for full flexibility.. And if the calculation is constrained to the current month, then there is a chance that having any offset at all could result in occasional unachievable window.
The documentation should clarify the method in which the calculation is performed ( current month, or current+previous, or current + N previous months, entire calendar, etc), and the allowable offset should be increased to 30 if calculations are constrained to current month. Or in the case of multiple month calculation, increase to 62, or even higher, depending on the methodology used in the engine that calculates the maintenance windows.
Then leave it to the customer to decide what day offsets work for them, based on their needs instead of setting an arbitrarily low value that can be used an offset.
It would be nice to set the baseline day to Second Tuesday.. and then make all offsets from that date example.. +2, +7, +12, +14, instead of having to offset from third, fourth , etc.. to progress through the calendar.
In the case where the calculation is based on current month, I would also suggest adding something to the GUI/PowerShell ( if applicable ) describing the limitation and the bring attention to the possibility that you could configure a non-achievable value if you set the value too high. It should be documented in as many places as possible.
Hope someone can set the record straight on the calculation method part of this as that will either open the possibilities up... or narrow them down considerably.
Microsoft
