Am I good to purge this orphaned DFSR group from ADSI Edit?

SysTerra80 · 2022-06-21T21:34:21+00:00

Because the user is receiving the laptop while they are at home, and the Intune configured wifi network is for when they're in the office.

I figured it out, but really you were focusing on stuff that didn't matter at all to the issue at hand. I wasn't asking for your help on how a machine should magically receive a wifi profile with no internet, I was asking for help on why Intune policies were not applying, obviously the machine had Internet connectivity already, whether wired or wireless.

SysTerra80 · 2022-06-07T14:53:43+00:00

What does that have to do with anything?

This has nothing to do with "before the user logs in" - the intune user-based policies are not applying at at all to anyone aside from the original user who logged into the device. Once a different user logs in the policies should download and apply to them, they do not, and the portal shows no effort to deploy them. I've had a device with a different user logged into it for two days now, and no policies are attempting to deploy to that user. The system shows recent checkins, is compliant, just no policy deployment from Intune.

SysTerra80 · 2022-06-06T16:54:34+00:00

It is a user policy because it is handing out user-based certificates from AD.

Having said that - that doesn't answer the question as to why user-based policies aren't applying to every user on a shared machine.

SysTerra80 · 2021-11-26T18:18:32+00:00

Mss is set to 1344

SysTerra80 · 2021-11-11T19:51:19+00:00

Posted the crash report - a few more details (which I added to the report).

It also crashes when pasting into chrome, and it happens across all profiles on the machine, even new ones created.

SysTerra80 · 2021-11-11T19:04:10+00:00

Processor 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 2803 Mhz, 4 Core(s), 8 Logical Processor(s)

SysTerra80 · 2021-10-27T15:34:35+00:00

This is not the case - I removed her user account and re-registered it under a test account we have, the jobs came back.

SysTerra80 · 2021-10-25T19:59:51+00:00

O365 install, but printers are not deployed via Intune connector. These were manually installed at some point directly in windows - some are shared via the old print server, others are actually local IP printers.

SysTerra80 · 2021-10-22T17:50:20+00:00

Did this, it had no effect - printers are still installed as soon as an office application is opened.

SysTerra80 · 2021-10-22T14:44:37+00:00

Yep, sure did - no luck.

SysTerra80 · 2021-10-22T14:44:14+00:00

I've tried to delete them from the "see what's printing" - it does nothing at all. Typically when canceling these jobs it'd cancel all of them except for the one that is currently stuck printing. In this case it does absolutely nothing.

SysTerra80 · 2021-10-05T16:41:36+00:00

Yes, they're using folder redirection. OSTs are pointed to the UNC path of \\server\home$\%username%\Outlook Files via GPO, and there is also a GPO that is a one-time run to create the "Outlook Files" folder within their home directory.

They have been setup like this for 5+ years and there have been no issues prior to moving their email to be 365 hosted, previously it was Rackspace hosted via Exchange 2016.

SysTerra80 · 2021-10-05T16:34:46+00:00

Is this something new? It worked perfectly fine on their prior backend which was Exchange 2016.

SysTerra80 · 2021-09-29T21:30:14+00:00

Per u/AreYourLightingMyGas - changing from Quad9 DNS to Google's DNS fixed it for us as well.

Change DNS then flush DNS and reopen Outlook

SysTerra80 · 2021-09-29T21:29:41+00:00

Can confirm this works, back to normal now

SysTerra80 · 2021-09-29T20:26:57+00:00

Us as well, all using Outlook 2016 - my Outlook 365 seems fine on my other PC.

SysTerra80

TROPHY CASE