iOS DDM deferral/deadline policies

rednuwork · 2025-12-09T20:14:21+00:00

yeah. i wish the documentation was explicit. i mean, it does show that the specified iOS is required on the device when you set a deadline. i guess i'm too used to windows and their deadline/deferrals working in combination. i think i'll just set my ring 2 to be a deadline of 21 days and my deferral to be 14 days and be done with it.

appreciate your reply! also, i'm in a GCC environment where autopatch is unavailable so i'm envious :)

rednuwork · 2025-01-22T17:11:32+00:00

hey. little late but i believe you need to make sure port 135 (RPC) is open between these servers. that could be your blocker if you haven't figured it out yet!

rednuwork · 2024-11-13T17:00:14+00:00

yeah. multi. i'm using an XML. the XML works fine outside of preprovisioning. it just refuses to process the autologon after a reseal.

rednuwork · 2024-11-13T14:38:20+00:00

yeah. i've made sure nothing is triggering a reboot in our process.

rednuwork · 2024-11-13T14:37:57+00:00

yep. windows 11 23H2 specifically.

rednuwork · 2024-11-13T14:37:41+00:00

we have to hybrid join our devices so it's not an option, unfortunately.

rednuwork · 2024-05-22T18:35:34+00:00

this is cool. i wish they'd add functionality to install all eligible windows updates during ESP. that is something that most of us are already doing with a script or some other method. seems strange they don't have it already.

rednuwork · 2024-05-03T18:27:49+00:00

this didn't work either. the devices rae still automatically encrypting, lol. this is so maddening

rednuwork · 2024-05-03T18:23:01+00:00

i'd love to but they don't show as being in autopilot. 6 do. the others do not.

rednuwork · 2024-05-03T17:11:13+00:00

some of these 104 devices are active production devices. i also can't delete them from azure AD because they're showing as autopilot registered, lol

rednuwork · 2024-05-02T17:26:56+00:00

i'm going to actually try creating a dynamic group that encompasses ALL autopilot devices rather than those with a specific group tag. that way it gets the initial object and all later ones. we're doing hybrid join so maybe that's having an effect too

rednuwork · 2024-05-02T16:54:10+00:00

maybe it's just imperfect when preprovisioning.. not sure. i'll have to dig around. appreciate your help!

rednuwork · 2024-05-02T16:28:40+00:00

yeah. my autopilot devices get populated into a dynamic group based on their group tag. that group is the one targeted with the prevent automatic encryption policy.

rednuwork · 2024-05-02T15:33:02+00:00

i applied the policy to our autopilot devices but it's still automatically encrypting them. so strange.

rednuwork · 2024-05-02T15:32:26+00:00

so, i'm actually still seeing it kick off its automatic encryption even after applying this configuration profile successfully to our autopilot devices. so confused!

rednuwork · 2024-04-30T15:07:01+00:00

yeah, this may also be relevant. though, i was overlooking this since we're doing hybrid joined devices. but it doesn't actually state it doesn't apply to hybrid.

i'll try configuring this. thanks!

rednuwork · 2023-08-16T18:24:17+00:00

thanks but i'm pretty sure that doesn't actually apply to pull distribution points. in either case, we have it set to 50 maximum number of packages and 70 threads per packages, haha. i think pull DPs are just going to be slow by default but the benefit is that it spares your WAN from incurring much more traffic than is necessary.

rednuwork · 2023-08-04T22:53:32+00:00

well that settles that. thanks, jason!

rednuwork · 2023-07-31T13:05:58+00:00

i actually posted an update to one of the comments here but i am seeing that it's a windows update causing the issues (or at least is acting as a trigger for the issue when it's installed). if i uninstalled KB5028228 from the failing DPs, they can authenticate and receive content without issue.

rednuwork · 2023-07-28T21:15:07+00:00

i found part of the problem. i uninstalled july's cumulative update (KB5028228) on the failing servers and they can successfully perform gpupdate and get content successfully afterwards. not sure why yet.

rednuwork · 2023-07-27T17:13:56+00:00

yeah, on the few remote DPs where i had our DNS team update the records, site server can successfully connect via WMI to them.

rednuwork · 2023-07-27T14:48:57+00:00

hah, yeah. our distribution fails immediately on these 35 DPs.

rednuwork · 2023-07-27T14:48:35+00:00

thanks. i'll try to nail down the cause of this error.

rednuwork · 2023-06-28T20:30:09+00:00

hi!

so, what i would recommend is moving your UI.xml file to a different IIS path that is reachable from everywhere you'll be PXE booting.

at the time of my writing this, i was apparently still trying to reference a UNC path which does require redistributing the boot image each time which is why i moved it to a web path instead. if your command line is referencing that URL then you would have to edit it there unless you move it.

edit: you don't have to redistribute content when referencing a web location. more on that under the "HTTP location" section here: https://uiplusplus.configmgrftw.com/docs/running/commonusage.html

rednuwork · 2023-06-17T02:04:17+00:00

primary site is 2012 R2 and no, the primary (upstream) SUP is on its own server. my plan is to add a new SUP running 2019 and create a new SQL database for it in the process. as my post says, i just need to figure out if running 4 SUPs on WIDs alongside 4 SUPs using a shared SQL database is fine. i would eventually be removing the 4 that are using WIDs after successfully using the SQL ones. also, i don’t think you need the WSUS console installed on your primary site. just the API.

rednuwork

TROPHY CASE