Closed CubeWT closed 6 months ago
Do you mean that you'd prefer the Scope Tag to be backed up with the name in the output instead of ID as well as being checked when updating if that Scope Tag exists with the name and if not removing it from the config being updated/created?
Yes correct. Currently if a Configuration is save with ScopeTag ID 11 in Tenant A und restored in Tenant B, where a ScopeTag with ID 11 doesn't exist, the Configuration will be created with "Scope Tag deleted".
In the worst case, in Tenant B is a Scope Tag with ID 11 but it's not the same scope as in Tenant A.
Because of this i would prefer that the matching happens with the displayname of the scope rather than the ID.
Okay so basically there needs to be some processing of Scope Tags on configurations on both backup and update so the id
is switched with the name in the saved output and checked against the target tenant, if the name is not in the target tenant, remove it from the payload being pushed so there is no conflicts
Yes this would be sufficient, thanks.
I have added processing of scope tags in 2.2.0-beta3, please test this version and verify the scenarios you have described are working.
Backup Payload | Working |
---|---|
Apple Push Notification | Not tested |
Apple Volume Purchase Program tokens | Not tested |
Application Configuration Policies | Not tested |
Application Protection Policies | Yes |
Applications | No |
Compliance Policies | Yes |
Conditional Access | Not tested |
Device Categories | Yes |
Device Configurations | Yes |
Device Management Settings | Not tested |
Group Policy Configurations | Yes |
Enrollment profiles | Yes |
Enrollment Status Page | Yes |
Endpoint Security | Not tested |
Filters | No |
Managed Google Play | Not tested |
Notification Templates | No |
Proactive Remediation | Yes |
Partner Connections | Not tested |
Shell Scripts | Yes |
Custom Attributes | Not tested |
Powershell Scripts | Yes |
Settings Catalog Policies | Yes |
Enrollment Configurations | Yes |
Windows Driver Updates | Yes |
Windows Feature Updates | Yes |
Windows Quality Updates | Yes |
Roles | Yes |
Scope Tags | Yes |
Activation Lock Bypass Codes | Not tested |
Remarks Applications are not working but i think scope tags are generally not supported for applications or? Filter are not working and i would assume because the propertyname for filters is "roleScopeTags" and not "roleScopeTagIds".
Update Will i check tomorrow.
Looking in to the Applications, the scope tags are not included because I do a bulk list of all apps and export them, If scope tags should be included, unfortunately, a request per application needs to happen. Could potentially increase run-time. Question is how big of an issue that is as apps cannot be updated.
I will check the filters, why keep it uniform Microsoft 🙄
I have a fix for apps and filters, I will publish Beta 4 soon!
Beta 4 is now pushed which includes fixes for apps and filters.
Thanks i will test it tomorrow. Apps is not important for me, thought i mentioned it. Maybe i've marked it better in the table but "Notification Templates" has also not worked.
Found the bug for notification templates and will include the fix in a later beta or release
Backup Payload | Working |
---|---|
Apple Push Notification | N/A |
Apple Volume Purchase Program tokens | Yes |
Application Configuration Policies | Yes |
Application Protection Policies | Yes |
Applications | Yes |
Compliance Policies | Yes |
Conditional Access | N/A |
Device Categories | Yes |
Device Configurations | Yes |
Device Management Settings | N/A |
Group Policy Configurations | Yes |
Enrollment profiles | Yes |
Enrollment Status Page | Yes |
Endpoint Security | N/A |
Filters | Yes |
Managed Google Play | N/A |
Notification Templates | Yes |
Proactive Remediation | Yes |
Partner Connections | N/A |
Shell Scripts | Yes |
Custom Attributes | Yes |
Powershell Scripts | Yes |
Settings Catalog Policies | Yes |
Enrollment Configurations | Yes |
Windows Driver Updates | Yes |
Windows Feature Updates | Yes |
Windows Quality Updates | Yes |
Roles | Yes |
Scope Tags | Yes |
Activation Lock Bypass Codes | N/A |
Hello, i've tested the Update mechanism and i get errors during the initial creation of objects. Based on the error output i would assume that the converting from the ScopeTag name to ID has problems.
The initial creation of ScopeTags itself is working and also the update on existing objects to a new ScopeTag Id, to resolve the "Scope Tag Deleted" message.
For App Protection, Device Category, DeviceConfiguration and maybe other
Profile not found, creating profile: TEST-PROFILE
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\testuser\2.2.0-beta3\Scripts\IntuneCD-startupdate.exe\__main__.py", line 7, in <module>
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\run_update.py", line 308, in start
run_update(
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\run_update.py", line 229, in run_update
update_intune(
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\update_intune.py", line 75, in update_intune
update(path, token, assignment, report, create_groups, remove, scope_tags)
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\update\Intune\update_profiles.py", line 337, in update
post_request = makeapirequestPost(
^^^^^^^^^^^^^^^^^^^
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\intunecdlib\graph_request.py", line 206, in makeapirequestPost
raise requests.exceptions.HTTPError(
requests.exceptions.HTTPError: Request failed with 400 - {"error":{"code":"BadRequest","message":"{\r\n \"_version\": 3,\r\n \"Message\": \"Invalid Role Scope Tag defined TESTSCOPE - Operation ID (for customer support): 00000000-0000-0000-0000-000000000000 - Activity ID: da38f326-246f-4283-bd88-546447b6129e - Url: https://fef.amsub0202.manage.microsoft.com/DeviceConfiguration_2402/StatelessDeviceConfigurationFEService/deviceManagement/deviceConfigurations?api-version=5023-11-15\",\r\n \"CustomApiErrorPhrase\": \"\",\r\n \"RetryAfter\": null,\r\n \"ErrorSourceService\": \"\",\r\n \"HttpHeaders\": \"{}\"\r\n}","innerError":{"date":"2024-02-29T05:16:51","request-id":"da38f326-246f-4283-bd88-546447b6129e","client-request-id":"da38f326-246f-4283-bd88-546447b6129e"}}}
And for Autopilot Profile, Enrollment Status Page
Autopilot profile not found, creating profile: TEST-AP-ENROLLMENT
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\testuser\2.2.0-beta3\Scripts\IntuneCD-startupdate.exe\__main__.py", line 7, in <module>
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\run_update.py", line 308, in start
run_update(
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\run_update.py", line 229, in run_update
update_intune(
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\update_intune.py", line 94, in update_intune
update(path, token, assignment, report, create_groups, remove, scope_tags)
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\update\Intune\update_windowsEnrollmentProfile.py", line 145, in update
post_request = makeapirequestPost(
^^^^^^^^^^^^^^^^^^^
File "C:\Users\testuser\2.2.0-beta3\Lib\site-packages\IntuneCD\intunecdlib\graph_request.py", line 206, in makeapirequestPost
raise requests.exceptions.HTTPError(
requests.exceptions.HTTPError: Request failed with 400 - {"error":{"code":"","message":"The request is invalid.","innerError":{"message":"windowsAutoPilotDeploymentProfile.RoleScopeTagIds : Property RoleScopeTagIds, all items must be less than length 5\r\n","date":"2024-02-29T05:17:39","request-id":"05b74749-198c-475f-8fd2-bccfd9428c63","client-request-id":"05b74749-198c-475f-8fd2-bccfd9428c63"}}}
Is the above error in a scenario where the scope tag on the payload does not exist in the target tenant?
Ah, I think I see what's happening, it's not doing the conversion if the payload cannot be found and is created in the target tenant
I'll fix it and push a new beta today
Beta 5 is being pushed now, please test this version and make sure the scope tags are correctly processed when updating and creating policies.
Hello,
i've tested the new version and everything is working (backup, update, initial creation) for all objects except for enrollment status pages.
If the ESP doesn't exist in the tenant i get an error. When i change the ScopeTag Name manually in the JSON to the corresponding ID it's working.
Enrollment Status Page profile not found, creating profile: TEST-EnrollmentProfile
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\testuser\2.2.0-beta5\Scripts\IntuneCD-startupdate.exe\__main__.py", line 7, in <module>
File "C:\Users\testuser\2.2.0-beta5\Lib\site-packages\IntuneCD\run_update.py", line 308, in start
run_update(
File "C:\Users\testuser\2.2.0-beta5\Lib\site-packages\IntuneCD\run_update.py", line 229, in run_update
update_intune(
File "C:\Users\testuser\2.2.0-beta5\Lib\site-packages\IntuneCD\update_intune.py", line 101, in update_intune
update(path, token, assignment, report, create_groups, remove)
File "C:\Users\testuser\2.2.0-beta5\Lib\site-packages\IntuneCD\update\Intune\update_enrollmentStatusPage.py", line 169, in update
post_request = makeapirequestPost(
^^^^^^^^^^^^^^^^^^^
File "C:\Users\testuser\2.2.0-beta5\Lib\site-packages\IntuneCD\intunecdlib\graph_request.py", line 209, in makeapirequestPost
raise requests.exceptions.HTTPError(
requests.exceptions.HTTPError: Request failed with 400 - {"error":{"code":"","message":"The request is invalid.","innerError":{"message":"configuration.RoleScopeTagIds : Property RoleScopeTagIds, all items must be less than length 5\r\n","date":"2024-02-29T08:57:11","request-id":"563ce057-cce6-4718-8fa2-465bffd72dea","client-request-id":"563ce057-cce6-4718-8fa2-465bffd72dea"}}}
Found the bug for ESP and it has been fixed locally for me
Fixed in beta 6
Verified. Initial creation of ESPs with scopetags and update of scopetags is working
Describe the bug If a configuration is imported in a Tenant and the custom ScopeTag IDs differ between the Tenants, the Configuratin is imported without error but under the ScopeTag section of this configuration the missing ScopeTags are listed as "Scope Tag Deleted".
To Reproduce with 2 Tenants
with 1 Tenant
Expected behavior If a ScopeTag already exist in a Tenant, the ScopeTag ID of the Destination Tenant is used and not the ScopeTag ID of the Source Tenant. So it would be better if the matching is happening based on the ScopeTag Name rather then the ID.
Run type (please complete the following information):
Additional context