lparry

Hunter2 is secure for us

Another important ESP note - don't try and install LOB apps (MSI's etc.) as it can and probably will cause you issues - see quote from Andrew Taylors blog below as he is much better writing it down than me! But we are the same as @Squelch pretty much - We don't push any apps during ESP stage and find they are good to go in a hour or so unless its a computer with the Adobe suite as that can hang!

I know I shouldn't be surprised but how is this the timeline we now live in

Our move to cloud was rough (tills not working, biometric server just shutting off causing fingerprints not to be recognised, weird reporting quirks, FSM issues)... However these have been ironed out and to repeat what hallamke said, as of late the ticket resolution time seems to be same day rather than days/weeks so your experience should hopefully be better!

Just out of curiosity as this has always been my sticking point from going 100% cloud - how would you manage the below situation? Our computer labs are shared between both sixth form and Y7/11 students, both groups have different restrictions which gets applied ruling out having device based policies. When using intune - user based policies don't always apply fast enough leaving computers in a brief but exploitable whilst it syncs. How is it possible to ensure the policies are applied prior to users being able to access the machine? I haven't properly delved into it for a 1.5/2 years but when I last looked, this is what caused the project to be shelved

You have an idea of what exactly these devices will be doing? - Haven't been in the exact same predicament but should be able to tell you if you are in for a bad time or not!

I suspect you could specify it to pull from a local share fairly easily - I definitely know it can cache the download to the boot USB and just pull the files from that any subsequent deployments.

The way I've done it - Autopilot.json profile gets injected during OSDCloud install adding it to Intune/Entra. This then falls into a dynamic group (enrollmentprofilename -eq "AutopilotID") which gives it the domain join config/renames the device etc. No reason why you couldn't due a .PPKG though as thats built into OSDCloud as well I believe

Like a british bringus (even have HL2!) - It was an enjoyable watch Looking forward to more 👀

That'll be it if they are showing as devices but not being prompted during setup to enroll 👍

It should be the same enrollment token. To get the potentially silly question out of the way, have they got an MDM assigned in ASM so it knows to go to Intune?

Yup - same issue here, no active issue listed on service health yet but have to assume its an outage

Time synced across both DC's so that rules that out. Decided to repadmin /removelingeringobjects the DC's again even though advisory mode showed 0 objects as a hail mary and it might have improved the situation. Update to follow!

Morning everyone! For some reason - one of our domain controllers have decided that it no longer wants to replicate and instead chucks a not massively helpful error of '8 (0x8): Not enough memory resources are available to process this command.' which brings up little about replication errors when googled. Things tried so far: Checked for lingering objects between the two domain controllers - nothing found Attempted to force a replication - same error persists. Restarted DC VM - no improvement. Restarted Host - no improvement. Only thing standing out but is most likely a red herring is the DNS service is being a bit memory hungry but there is still 8GB of headroom left. Anyone seen this replication issue before? Any ideas? Any help appreciated!

Sadly probably the only way in that case! I'd start with removing all of one type of app (LOB or Win32 - preferably LOB) and going from there. There's a good explanation of what could be happening in the background by someone smarter than me: