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:

Just to circle back to what @itskdog asked - do you have a mix of LOB and Win32 packaged apps? Can you shift+f10 out to a CMD windows and use microsoft's MDM diagnostic tool to generate some logs? (mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:\Intune\Log.cab)

Didn't even realise this was a thing - joined under lparry

Two options off top of my head if either fits your needs: My go to but involves fiddling with drivers: This guide has a nice how-to about packaging printers in Win32 apps with an install and uninstall script - used it successfully many times without issue. https://msendpointmgr.com/2022/01/03/install-network-printers-intune-win32apps-powershell/ Device restrictions > Printers Under the device restrictions configuration profile you can specify domain printers to be added - only used it once so can't give it a solid review but seemed to work without issue

After years of not wanting a smart watch and always sporting an automatic fossil - finally made the plunge and got a Huawei D2 following some health scares last year! Still blows my mind that the cuff inflates!

Odd - I'm currently in the middle of doing a zabbix project myself! What are you trying to monitor? - If it's just simple data (total counts of clients, devices, etc.) then it would probably be easier just to use their API to grab data from the controller: If you need visibility down to the devices themselves - I have some templates I quickly knocked up for device hostname, model, uptime and interface discovery I'm happy to share as a starting point but I will warn you - they aren't complete and a bit rough! Rather than trying to import the whole MIB, I'd say just SNMPwalk and add the OID's you need for your use case as items, If I remember correctly the below dug out of my OneNote are some UBNT specific ones however most I found used standard MIB's: .1.3.6.1.4.1.41112.1.6.3.1.0 = IPADDRESS: 192.168.0.254 <IP Address .1.3.6.1.4.1.41112.1.6.3.2.0 = INTEGER: 0 .1.3.6.1.4.1.41112.1.6.3.3.0 = STRING: "UAP-AC-Pro-Gen2" <-model .1.3.6.1.4.1.41112.1.6.3.4.0 = STRING: "eth" .1.3.6.1.4.1.41112.1.6.3.5.0 = COUNTER32: 3528628 <-uptime clock .1.3.6.1.4.1.41112.1.6.3.6.0 = STRING: "3.9.42.9152" <-firmware

Back to work 😒

Exactly how I first noticed, then went to check downdetector (which is also down). Had to go to https://downdetectorsdowndetectorsdowndetectorsdowndetector.com/ as downdetector's downdectector is detecting downdetector is up while downdetector is down.

Happy friday!

Glad it's not just ours!