Microsoft is unlocking the "Full Potential" of Private Channels in Microsoft Teams: What You Need to Know

It has been a while since I posted something just about a Microsoft Teams update, as a lot have been Copilot in Teams to be honest. But here is a real Microsoft Teams update I think is worth knowing about, and it involves Security and Compliance as well. Microsoft is rolling out a "major" update to private channels in Teams, starting in late September 2025 and continuing through mid-December. This biggest change in this update is a shift in how private channel data is stored from individual user mailboxes to a dedicated channel mailbox. Not only will this simplifie compliance management, it will also and align private channels with shared channels, making governance and experience more consistent across Teams. This update promises to increase the support up to 1000 channels per team and 5000 members per channel, removing previous limitations. Teams will also allow meetings to be scheduled directly within private channels, enhancing collaboration.  For organizations using Micr...

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.