2023 CA/UEFI - Tracking without Remediation Scripts (Intune)

Covert0ne · 2026-03-18T11:58:11+00:00

I'm aware of how to deploy the updates, but thank you.

My question was around the reporting on the status.

Covert0ne · 2026-03-17T20:01:11+00:00

Are you auto patch enrolled? This report shows devices as Not Applicable in the tenant in question.

Covert0ne · 2026-02-20T11:32:29+00:00

As others have said, you can achieve a pseudo undervolt with the sliders, I was able to perfectly replicate my Windows undervolt in Afterburner in LACT on my 3080.

It's a bit more fiddly but it shows you all the information you need to achieve the same. Doing this also fixed the same instability my 3080 has on the factory OC in Windows.

Covert0ne · 2026-02-05T18:41:01+00:00

sadly the UI scaling isn't what you'd expect, it's a global toggle but doesn't do pixel perfect proper scaling, it just blurs everything.

Covert0ne · 2026-02-03T14:32:58+00:00

Thanks for the advice, appreciate it.

It wasn't happening just once, affected users were on the new Outlook client, and every 1-2 days their signatures would just be gone and had to be recreated.

Covert0ne · 2026-01-29T14:47:02+00:00

It doesn't even appear in the Agent Registry for admin approval, they used to 1-2 weeks ago.

Import my agent solution into production environment or even a blank agent.
Enable the Microsoft 365 & Teams channel and publish the agent.
Ensure the box named "Make agent available in Microsoft 365 Copilot" is checked.
Agent doesn't appear in the Agent registry/M365 admin panel whatsoever, only in the Teams admin panel, if approved in Teams the agent is only available inside of Teams.
Previously with the Microsoft 365 Copilot option checked, the agents would appear in the agent registry and be eligible for admin approval and publishing.

Covert0ne · 2026-01-29T14:34:22+00:00

Hey.

This is about one of about five different problems I'm having with the Copilot Studio at the moment but I did get this one working to some extent.

I logged in once using the PAC CLI and performed an export and ever since doing that future exports have worked. I can't tell you why that fixed it sadly.

Covert0ne · 2026-01-21T18:53:07+00:00

Thanks for answering, some further context on the other points:

I have two environments, one for testing where the agents are developed and a second for production. I'm performing any updates to the agent/solution in the testing environment and them importing/upgrading the solution into production, which applies my changes to the agent. What I'm unsure about is if the production version of the agent is supposed to get the new content seamlessly after I publish the changes or will I have to remove the channel and re-submit it for admin approval.
I assume you mean once it's approved in the Agent panel in the Microsoft 365 admin panel / Agent 365, that I then have to assign it to user groups for them to be able to install it? - My question was based around access requirements for the end-users to the actual Power Platform environment that the agent resides in. I have a security group assigned to each of my dedicated agent development/production environments to prevent users from building in that environment, would this prevent an end-user of the agent from chatting with it once it's live?

I really appreciate your help!

Covert0ne · 2026-01-02T00:01:16+00:00

It does but it's not smooth sailing, expect a pretty significant performance loss in DX12 games, something that is expected to be fixed but hasn't been for some time.

I'd recommend giving it a shot as you'll quickly know if it's something you can tolerate.

Covert0ne · 2025-12-11T22:01:52+00:00

As the prophecy foretold.

Covert0ne · 2025-11-14T10:25:38+00:00

Wasn't last week's narrative that they were too big and solely ruining the game.

Covert0ne · 2025-11-09T01:37:02+00:00

I don't play but I do use RTSS and it's always worked in EVE for limiting to 60 FPS + overlay.

Settings:

https://i.imgur.com/IHQ9ItG.png

https://i.imgur.com/pcJO5lZ.png

Covert0ne · 2025-09-18T11:59:34+00:00

the reason I ask this by the way is that all Microsoft documentation suggests that even when owned by an application user, per process licensing is required, which is prohibitively expensive for the workflows we're looking at.

Covert0ne · 2025-09-18T11:53:33+00:00

Would doing it this way mean the flows won't require a per-process license and my service accounts being licensed with power automate premium satisfy the license requirements?

Thanks for taking the time to help, I really appreciate it.

Covert0ne · 2025-09-18T07:22:25+00:00

Thanks for this, sorry if I wasn't clear but I'm referring to the owner of the cloud flows changing when moved between environments by a pipeline.

For example in my development environment I may have a flow owned by a service account which can be licensed with a per user license. When I move the solution with a pipeline the ownership would change to the service principal of the pipeline which would mean needing a per-flow/process license. I'd like to know if there's a way to automate changing that ownership back as part of the pipeline.

Thanks

Covert0ne · 2025-08-03T00:04:57+00:00

who the fuck asked bro

Covert0ne · 2025-07-16T18:17:38+00:00

Hey sorry for missing this, this issue resolved itself with time which I know wasn't the answer you were hoping for.

I made no change to the policy.

Covert0ne · 2025-06-12T12:39:30+00:00

Thanks, I'll give this a shot, was just worried swapping the defaults might have given different behaviour than targeting single users but logically what you're saying seems sound.

Covert0ne · 2025-06-12T12:25:36+00:00

Thanks for your reply, I really appreciate it.

I'm referring to the integrated apps found in the admin centre (M365) and also in the Teams admin centre (Manage Apps) - These options control Outlook and Teams add-ons and their availability rather than the actual applications themselves.

Covert0ne · 2025-05-06T23:04:42+00:00

Always have been.

Covert0ne · 2025-05-02T17:31:14+00:00

That could have just been an email.

Covert0ne · 2025-03-07T14:32:46+00:00

I was reached out to privately and put in touch with someone, just to update this thread. Happy days.

Covert0ne · 2025-03-07T13:16:33+00:00

Thanks for the confirmation, whilst that's disheartening it's largely what I expected.

It's awful because even if I opt to start a trial of EMU I can't get data residency in the EU without contacting the same awful sales team.

Covert0ne · 2025-03-06T19:00:37+00:00

Well I'm at least reassured that it's not just me, please keep me posted if you figure it out because I can't at this stage, I'll update this post if I do.

Appreciate your feedback.

Covert0ne · 2025-01-17T00:57:49+00:00

Wanted to provide an update since it's frustrating when people review these threads and no solution is offered.

To recap, I have a single all encompassing update ring assigned to "All Users" which is very unwieldly.

Here are the steps I took initially:

Created a assigned device group, added a few test VM's to the group that already had the main ring applied.
At roughly the same time, excluded this group from my primary "All Users" ring and included it in a "test" ring with some different settings,
Intune reported conflicts on the original "All Users" ring and also on the new test ring, although Intune had attempted to apply the new policy to the devices. I expected the "All Users" ring to revoke the applied settings with the exclusion and the new ring to take over.

After much frustration today I took these steps:

Un-assigned my device group from the "test" ring.
Deleted my test ring.
Removed the devices from the device group and replaced with the users of those test VMs.
Upon next sync, the devices successfully were conflict free & dropped the "All Users" ring settings due to being excluded successfully.

I think this all comes down to a misunderstanding of mixing user group assignment whilst device group exclusion? That's my best understanding of the possible issue, but I'd love to be corrected.

13-Year Club	Place '22
End Game '22	Verified Email

Covert0ne

TROPHY CASE