Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intune Windows Feature Update Profile - Handling for rollout settings #4614

Closed
FabienTschanz opened this issue Apr 26, 2024 · 1 comment · Fixed by #4910 or #4923
Closed

Intune Windows Feature Update Profile - Handling for rollout settings #4614

FabienTschanz opened this issue Apr 26, 2024 · 1 comment · Fixed by #4910 or #4923

Comments

@FabienTschanz
Copy link
Contributor

FabienTschanz commented Apr 26, 2024

Description of the issue

The resource IntuneWindowsUpdateForbusinessFeatureUpdateProfileWindows10 is responsible for making Windows 10/11 upgrades available for a subset of devices. It contains a property RolloutSettigs, that holds the following values:

  • OfferStartDateTimeInUTC - Start time of the update
  • OfferEndDateTimeInUTC - End time of the update (optional)
  • OfferIntervalInDays - Interval between each groups (optional)

When exporting an existing policy with a OfferStartDateTimeInUTC (and optionally end time and interval) and reimporting the configuration in another tenant, the following exception will be thrown:

[BadRequest] : { 
  "_version": 3, 
  "Message": "An error has occurred - Operation ID (for customer support): 00000000-0000-0000-0000-000000000000 - Activity ID: d89897de-f7b0-47b7-b966-511ea2dc7e32 - Url: https://fef.amsub0102.manage.microsoft.com/Updates/SoftwareUpdateService/f42d0733-ffff-2221-0405-042102384327/deviceManagement/windowsFeatureUpdateProfiles?api-version=5023-07-14", 
  "CustomApiErrorPhrase": "", 
  "RetryAfter": null, 
  "ErrorSourceService": "",
  "HttpHeaders": "{}"
} 

The error occurs because the start time in the exported configuration is behind (current time + 2 days), which is required by the API to make the update available. This requirement cannot be changed. In my opinion, we should adjust the start time to the minimum required time and then create the policy.

Additionally, two more question arise with the handling:

  • What do we do if we want to create a new policy but the start and end date are in the past? Do we just let it fail? Or is checking the start / end time for a valid timespan (meaning at least end time is in the future) in Test-TargetResource a better idea, with returning True if both times are in the past? True in that case means that the policy would have no effect on the environment and thus is compliant with when no policies exist.
  • What is the "correct" way to check the resource in terms of timestamp matching, meaning if there is a mismatch e.g. in the start time but not in the end time? Currently, Test-TargetResource would return false, which leads to us trying to update the policy's start time. But that won't work if the start time is in the past.

I'm proposing the following resource handling changes:

  • Introduce the following changes to Set-TargetResource:
    • Creation / Update: If both start and end time are in the past, throw an error.
    • Creation / Update: If end time is less than start time, throw an error.
    • Creation: If start time is in the past but end time is in the future (by more than two days), adjust the start time to two days in the future and create the policy.
    • Update: If desired start time is different compared to actual but less than (current time + 2 days) and end time is different but more than 2 days in the future, keep the previous start time and only update the end time.
  • Introduce the following changes to Test-TargetResource:
    • If both start and end time are in the past or less than (current time + 2 days) with the current state being Absent, return True because creating a policy with start/end times in the past does not have any impact.
    • If desired start time is different compared to actual but less than (current time + 2 days) with the current state being 'Present' and end time is the same, return True because changing the start time to a date less than two days in the future is not possible.

Microsoft 365 DSC Version

V1.24.417.1

Which workloads are affected

Intune

The DSC configuration

IntuneWindowsUpdateForBusinessFeatureUpdateProfileWindows10 "IntuneWindowsUpdateForBusinessFeatureUpdateProfileWindows10-FeatureUpdate"
        {
            ApplicationId         = $ConfigurationData.NonNodeData.ApplicationId;
            Assignments           = @();
            CertificateThumbprint = $ConfigurationData.NonNodeData.CertificateThumbprint;
            Description           = "";
            DisplayName           = "FeatureUpdate";
            Ensure                = "Present";
            FeatureUpdateVersion  = "Windows 11, version 23H2";
            Id                    = "f2ba41f0-3cc0-493f-82c4-88a08cbfa45c";
            RolloutSettings       = MSFT_MicrosoftGraphwindowsUpdateRolloutSettings{
                OfferEndDateTimeInUTC = '2024-02-28T23:00:00.0000000+00:00'
                OfferStartDateTimeInUTC = '2024-01-17T23:00:00.0000000+00:00'
                OfferIntervalInDays = 7
            };
            TenantId              = $OrganizationName;
        }

Verbose logs showing the problem

No response

Environment Information + PowerShell Version

No response

@ricmestre
Copy link
Contributor

This one is an oldie, I forgot you raised an issue for it since I also had raised another issue even earlier #3438.

Even when creating this profile through the admin portal with start and end dates it's a pain in the neck, lots of trial and error until you select the correct dates and it let's you save so I'm OK with all your changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants