I did my first podcast episode back in March. Because I didn’t know any better, it was posted at a higher bitrate than necessary, so it used up a significant amount of the monthly quota on the service that is hosting the audio. No problem, I thought, as the quota is reset at the beginning of the next month, and it’s unlikely I’ll post another one before then anyway.
I was right, it took a while to do #2, but I missed April altogether – the month was a blur. Last night I posted episode #2, talking about group tags and other various things.
I’ve made progress on the publishing too, so you can now find this on various services:
- Spotify (which already sees episode #2)
- Apple Podcasts (which should show this episode within the next several hours)
- iHeartRadio (I assume it will notice the new episode eventually)
- Google Podcasts (which might have been slow to initially discover the podcast, but now seems to be the first to pick up new episodes)
And I suspect that’s broad enough for your favorite podcast app to pick it up – search for “OOFHours” and you should find it.
Out of Office Hours – Michael Niehaus’ technology ramblings
If you’re desperate or impatient (which would be weird), here’s the direct link:
Categories: Windows Autopilot
Hi Michael,
Thanks for a great blog and podcast!
I have a question regarding the reboot behavior you talk about in the last part of the podcast.
If I assign a WUfB policies to a user group instead of a device group, the device will not reboot during AP provisioning, and it seems that the WUfB policies are applied fine.
My question is, can I target policies that causes reboot during AP provisioning to a user group to avoid the extra reboot/login during provisioning, and will it have any negative consequences?
Best Regards,
Nicklas
LikeLike
As long as the policy isn’t needed at first user logon, that should be fine. (Examples would be policies that block consumer features/installing store apps, start menu layouts.)
LikeLike
That makes sense, thanks – i will stick with assigning most policies to user groups to avoid the extra reboot during provisioning.
LikeLike
Hi Michael,
first of all let me thank you for your great blog and effort to share so much knowledge to us.
We are recently using group tags and dynamic rules to assigning a “kiosk” profile to some of our devices.
While this is working perfectly on switching a “default” client (- devices from stock and already imported by our oem -) to a “kiosk” client,
we assume we may have discovered a *rough edge* on switching those devices back to a “default” client.
If we set the group tag (back) to an *empty string* the profile assignment isn’t performed even if we are very patient.
We can validate that both dynamic rules ~“all clients except kiosk” and ~“kiosk clients” working as excepted.
This edge case was discovered while we doing quality testing on “kiosk” restrictions.
Due a small amount of test hardware we have to switch often between the “default” and “kiosk” profile.
Can you may confirm a “restriction” on an *empty string* for the group tag that isn’t e.g. synced in every place for performing the profile assignment (windows enrollment)?
If not,
on which sync or data relies the profile assignment and what could be a good troubleshooting advice for us?
We could figure out on our own that a switch back to a tag like “default” (just another non-empty string) is working even fine as a workaround for this case/device.
Best Regards,
David
LikeLike
I’ll check on that. I know we’ve seen issues with the computer name (you can’t remove it after setting it), so this could be related.
LikeLike