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

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 script/application to reroute a specific number

There are many Lync installations out there in a need of a 3rd party switchboard. In some of these installations the switchboard number is non-existent for the Lync environment (it is no more than a voice route to a pstn gw through a mediation server). And if we do nothing, the incoming call to the switchboard will be rejected by the registrars as "no user configured with this number" aka user not found.

I found a "dirty way" of fixing this, by creating a unassigned rule for it. Catching the number, sending it (targeturi) to a new destination and then translate it to the correct number on the way to the switchboard application server (through a pool trunk).

The problem with this, is the way it has to be set up, with several translations and rewrites. It became rather difficult to troubleshoot.

My solution to the challenge turned out to be to create a new server application, run before any other app, to catch the call and reroute the sip call to the trunk directly. And this is how I did it:

First of all, I downloaded and installed the "Lync server 2010 sdk" (found here) on the Lync frontend servers. And then I tried to my best to understand the documentation (located in the sdk installation, or online found here).

As it turned out, I was to fresh in the game to understand every little detail I had to think of, and needed some examples to work from. After doing some searches in forums and blogs related to the subject, I finally stumbeled upon a script created for OCS 2007 R2.

I took the script, and modified it to suit my needs, and Lync's way of addressing trunks (not mediation servers) in the reroute statement. It turned out to be quite easy, and I would like to share the script with you.

First we have to create the manifest, and describe what we are looking for. This is done by using standard methods well described in the documentation. One of the important things to notice, is the appURI which has to point to an existing dns entry. The final part is case sensitive, and must match what you later use in Lync Powershell when creating the application. The other thing I want to highlight, is the "requestfilter" which has been set to inspect the "INVITE" element.


Next we look through the sip messages, and try to filter out those messages which do not concern us. Things like "ignor none sip messages, ignore re-invites and ignore calls from other servers.


Then, we have to tell the application what to look for:


And finally we do the lookup and reroute to the static information. A quick note about the new to sip uri. This is set up to route directly to the PSTN GW defined as the destination in the topology, with both port and name of the designated mediation server (to save lookup time).



With the script all finished, save it to disk on the frontend server, and note the path.

Next, it's time to add the application to the frontend server. This is done by running the new-csserverapplication cmdlet (about) (note: the name here is case sensitive and must match the statement in the application manifest. I have also set the priority to 0, so it is run first):

new-csserverapplication -identity "registrar:lyncpool.customer.com/RouteExternalToAttendant -uri "http://www.customer.com/RouteExternalToAttendant -priority 0 -critical $false -enabled $true.

Finally, if the application isn't run, try to stop and start the application server through cscp. Use the SDK apilogger to verify contact and execution. Monitor the eventviewer for application compilation errors.

That should be all. As before, I have a sample script right here for you to read through.

And thanks again to my ex-colleague and friend who helped me fix this in the middle of the night.