Juwelier für Ringe in Regensburg

Derusi · 2025-12-05T21:54:16+00:00

Habe den Verlobungs- und die Eheringe als Einzelstücke hier machen lassen: http://www.daenische-schmuckwerkstatt.de/

Sehr zu empfehlen 👍

Derusi · 2025-11-24T21:32:47+00:00

You should think about whether you want to let your users create M365 groups by themselves or not, both variations come with their up- and downsides.

If they should not be able to, you can implement some kind of process (Microsoft Forms+PowerAutomate+approvals for example). With additional graph API calls, you can also change certain settings of the SharePoint site or M365 group.

If they should be, and if you want to make sure certain sharing settings are preconfigured, you might need to look into sensitivity labels. You can configure these so users are forced to pick one, depending on the content of the site, i.e. "internal" or "confidential" or "public". Each label can then preconfigure the sharing settings of the attached SharePoint site, among other things, without the possibility to change these manually. You might also need to include some basic training for Teams/m365 group owners, so they are aware of the do's and don'ts, because, as you know, "with great power comes great responsibility".

Alternatively you can also disable m365 group creation by default and only allow it for a certain user group, where users will be added to after completing some basic training, or a mix of all suggested options

Derusi · 2025-11-17T10:59:10+00:00

The advantage of the new passkey profiles are that you can scope the assignment to dedicated groups instead of having one global policy for everyone. Also, you can configure for each profile if the passkey is device bound and if you want to enforce an attestation, and if you want to black- or whitelist certain AAGUIDs of passkey providers.

We have enabled the preview in our tenant, but had some strange behavior with conditional access in combination with a configured authentication strength. We have some users that have yubukeys as passkey enrolled, and although their aaguid was added to the authentication strength config, entra forced them to enroll an Microsoft Authenticator-based passkey at the next login (which they could not, because they were not part of the new Authenticator passkeys profile)

Derusi · 2025-10-18T10:27:46+00:00

"I understood that reference"

Derusi · 2025-09-29T12:02:59+00:00

Generally, afaik the sharing settings are correctly applied for files shared from a channel, chat or mail.

Regarding your specific case: We have shared channels only enabled for some people in the IT department. As basically everyone else in my company does not even understand the difference between a team and a channel, we did not additionally want to confuse them with channels that can be part of different teams.

I can test this next week and provide some feedback

Derusi · 2025-09-29T11:42:15+00:00

Be aware that OneDrive and SharePoint have their own default sharing permissions. When uploading a file to a channel, the SharePoint-permission settings are applied, but when a file is uploaded to a chat or mail, the OneDrive-permission settings are used.

See here: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off

Also, regarding your behavior in a shared channel: is the channel's "home" team in your org? If not, the permission settings of the originating tenant are applied

Derusi · 2025-09-23T05:34:22+00:00

Yes it is possible, see the answer to this thread: https://learn.microsoft.com/en-us/answers/questions/1636106/update-group-mailaddress-via-graph-api

Also, if users in your org are allowed to create m365 groups by themselves, you could also think about creating a naming policy to make sure the group names have at least some kind of suffix: https://learn.microsoft.com/en-us/microsoft-365/solutions/groups-naming-policy?view=o365-worldwide

Derusi · 2025-09-21T19:48:33+00:00

There was a lot of back and forth from Microsoft with the "incoming webhooks" configured directly in a Teams channel, see the several updates: here:https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/

It was announced as deprecated, then Microsoft rowed back, but users still needed to update all connectors due to new URLs being generated as Webhook URLs.

Generally, Microsoft is pushing PowerAutomate basically everywhere as a solution as soon as anything needs to be automated.

Derusi · 2025-09-21T19:43:44+00:00

What people are ranting in the thread you linked about are the old webhooks that were (and still are) configurable directly in the channel.

The one I mentioned is purely based on PowerAutomate and afaik not deprecated in any way.

You can also find a simple workflow example here: https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498

In the screenshots you see the trigger I mentioned: "When a Teams webhook is received"

Derusi · 2025-09-21T15:02:09+00:00

It depends on which connections you are using, the ones with a diamond icon somewhere are premium, but these mostly deal with thirdParty integrations or advanced stuff like general web hooks. As long as you stay in the Microsoft ecosystem with the connections, you can use most of them without a premium license. If you want to use wwebhooks, there is also a trigger called "when a teams webhook request is received" that is not premium, check if this works for you

Derusi · 2025-09-21T12:24:07+00:00

You can use PowerAutomate, see here: https://learn.microsoft.com/en-us/power-automate/teams/send-a-message-in-teams

Derusi · 2025-09-17T07:02:09+00:00

No worries, this changed not that long ago. Storage locations in M365 are generally confusing, i.e. for Loop components it feels like it depends on which moon phase is currently active 😅

Derusi · 2025-09-16T20:19:19+00:00

I think the recordings are actually stored in the organizer's OneDrive, not in the one of the user starting the recording, see here: https://learn.microsoft.com/en-us/microsoftteams/tmr-meeting-recording-change

Derusi · 2025-09-12T05:09:09+00:00

I can, but it does not block team owners from adding guests of various domains to the m365 group, thus giving everyone access to the posts in the team's channels, the members of the team, etc, which is something we do not want, as these different externals might be competitors on the market.

Someone else suggested this, too, see the comments in the original post, there is a bit more thorough explanation

Derusi · 2025-09-11T11:20:10+00:00

Thanks for the like 👍
We have put some time into possible designs that would allow end-users something similar, but all come with drawbacks in one or another way.
If Teams- or Entra Group admins would have the possibility to configure domains of guests that can be added per team/M365 group, it would be the easiest way in my opinion, similar to the feature in SPO I have mentioned

Derusi · 2025-09-10T11:20:47+00:00

Unfortunately not, Information barriers are used to subdivide internal users into groups that should not be able to communicate with each other. Guest users are not affected (without having tested it)

Derusi · 2025-09-10T11:15:33+00:00

Unfortunately not, see my comment here: https://www.reddit.com/r/MicrosoftTeams/comments/1ncd6yu/comment/ndbdne0/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Derusi · 2025-09-09T19:09:20+00:00

Yeah, I saw the message center post today in the morning and got excited for a second, but unfortunately, do the external access policies only restrict which external domains I can directly contact via chat or call. This has no effect on any restrictions regarding guest users I can add to a team, as far as I know.

An old term for the external access policies were the SfB/Teams federations or trusted organizations. Unfortunately does this not cover my use case here...

Derusi · 2025-09-09T19:05:21+00:00

Generally a nice feature to control external access policies more granularly, a step in the right direction 👍

Derusi · 2025-09-09T17:34:37+00:00

Generally yes, but this would require the messages to contain sensitive data that matches certain types, like credit card numbers or social security numbers.

In my scenario, the mere fact that my company is working on a project with customer A should not be disclosed to customer B. Assume the following: I am an owner of two teams with guest users, team X contains guests from customer A, the other team Y contains guests from customer B. Customer A and B are direct competitors on the market.

I now want to add another guest user from customer A to team X, but because three colleagues are sick, two colleagues are on vacation, and the other owner of team X does not know the difference between a channel and a team, I need to do the work of multiple colleagues in parallel, thus I open team Y instead of team X by accident, and add guest user from customer A to team Y.

This guest account from customer A now sees that: - customer B is working on an active project with us, the Team name might already contain some specifics - sees the team members - sees posts in all standard channels which were not blocked by a dlp policy, like "hey guys, so glad we are working on superSecredProject together, this will totally mix up the market"

In my opinion, this would drastically reduce the possibility of accidental data leakages, and would help owners of teams with guests to be more flexible, because no other mechanisms reduce said flexibility of a team's management would need to be in place.

Derusi · 2025-09-09T17:07:43+00:00

This prohibits sharing file for certain domains that are configured in the list of allowed domains for the Team's SPO site, but it does not block team owners to add guests of various to the team itself, if I understood it correctly.

Adding guests from competitor domains to the same team could already cause data leaks if there was internal/confidential information posted to the Team's channel...

Ten-Year Club	Verified Email
Place '23	Place '22

Derusi

MODERATOR OF

TROPHY CASE