Being able to create Message Cards or Actionable Messages in Microsoft Teams via a Logic App or an Azure Function is great. Especially if you can use this to invoke logic on your API and update the message in the Teams channel.
However, you don’t want everyone to invoke a management API endpoint you’ve exposed to ‘do stuff’ in your cloud environment. Normally, you’d want to authenticate if the user pressing the button (read: invoking the endpoint).
Read more →In my latest post, I’ve shown you how you can use Azure Functions in your Microsoft Teams flow to handle errors in your environment. This stuff works great in a couple of projects I’ve worked on, but what would be even more awesome is to reply to a message in Teams when an action has completed after a button is pressed.
Well, replying & modifying the original message with a status update is quite possible and I’ll show you how in this post.
Read more →In today’s world we’re receiving an enormous amount of e-mail.
A lot of the e-mail I’m receiving during the day (and night) is about errors happening in our cloud environment and sometimes someone needs to follow up on this.
At the moment this is a real pain because there’s a lot of false-positives in those e-mails due to the lack of configuration and possibilities in our monitoring software. The amount of e-mails is so painful, most of us have created email rules so these monitoring emails ‘go away’ and we only check them once per day.
Read more →Normally when you are creating new appointments via Outlook in your organization you are inviting everyone who should join the meeting. This works quite alright, but not something I wanted to do for a couple of meetings I am planning. The meetings I’m organizing are optional to everyone inside the company, therefore I don’t want to spam the inbox of everyone with a meeting most of them (probably around 95%) aren’t interested in.
Read more →For our automated deployments we have several Azure Organizational accounts in place. These are created within the Azure Active Directory.
Because these accounts are meant for services, we don’t want them to inherit the default password policy for renewing their passwords every X days. Lucky for us, you can configure this via PowerShell. A short how-to is written on MSDN.
The thing that isn’t written (or referenced) over there is how to run the MSOL cmdlets.
Read more →