Safeguarding Sensitive Data in Microsoft 365 Copilot with Purview DLP (GA Release)

on
The challenge with sensitive data and access to Copilot Microsoft 365 Copilot empowers users with AI-driven assistance across Microsoft 365 apps, but it also raises concerns about accidental oversharing of sensitive information. In response, Microsoft has extended its Purview Data Loss Prevention (DLP) capabilities to Microsoft 365 Copilot, allowing organizations to enforce information protection policies within AI workflows. The DLP for Microsoft 365 Copilot has been in preview for some time, but Microsoft has now announced it is released for GA (General Availability). Among some of the interesting features are new features like alerting and policy simulation. Key details:  Rollout Timeline: As of June 2025, the rollout has begun. It should be completed worldwide by late July 2025. Scope: Initially, DLP for Copilot was available for Copilot Chat scenarios. By the time of GA this is expanding to Copilot in core Office apps (Word, Excel, PowerPoint) as well. Ensuring that DLP prote...

Lync client may connect to a non federated partner, even if you though it should not.

on
Here is an "interesting" observation I did a couple of days ago. The customer has chosen not to allow DNS discovery of federated partners, but will allow federation with selected partners on the allow list. After a while with this configuration, the customer called me and told me they had mixed experiences with the solution. There were times when meetings with a partner (NOT on the allow list) actually would work, even if they expected the meeting to fail.

They asked me to verify the settings, and to investigate why some users reported they could connect to a meeting others couldn't.

This is what I saw on a client who failed to connect:




5 messages. And the interesting one would be the 504 message: "Can not route".



And then the client stops trying, as I would expect it to.

But here is an interesting twist. Log on with the same client from a remote connection (through edge), and then let's see what happens.



The client does not honor the 504 message "Can not route". It continues and connects to the meeting, unexpectedly. How can that be?

The interesting part is what happens after the 504 message. First the client acknowledges the rejection, but then it does something it didn't do on the inside. There is a new invite, trying to connect anonymously:



And this connection is allowed. Quite confusing for the end user, actually. But now they know.


It is important to note the user was allowed for federation in this scenario, but the domain in question was not in the allow list and DNS discovery was not allowed. Also, the organizer on the other side was allowing anonymous invites.