“Bring your AI to work” is here: Microsoft edition - What Multiple Account Access to Copilot means

on
Multiple Account Access to Copilot On October 1. 2025 Microsoft released a blog post explaining how employees now can use Copilot from their personal 365 plans to work on organizational data. This is of course, an extension of the already existing "Multi account" feature that was released for corporate accounts a "couple of months" ago. In other words, “bring your own Copilot” is now a real thing in Word, Excel, PowerPoint, Outlook, and OneNote on desktop and mobile, with enterprise protections intact. “Bring your AI to work” is an important topic, and banning AI altogether might not be the answer. Whether sanctioned or shadow, AI has already entered everyday knowledge work. Microsoft’s new multi‑account access offers a safer path where employees can use Copilot from their personal Microsoft 365 subscriptions on work files, while the file’s access, auditing, and compliance still flow through the work identity and tenant. That’s better than users copy‑pasting sensit...

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.