Category Archives: Office 365

Microsoft 365 for IT Pros (2027 Edition)

Posted on by
Reply

It is that time of year again. The new edition of Microsoft 365 for IT Pros is out, and this one brings the biggest structural change we have made in years. What used to be one large book with a single companion volume has now grown into a bundle of four focused books. Splitting the content allows us to go deeper while keeping the main book maintainable. Together, they deliver more than 1,700 pages of practical guidance for people who run Microsoft 365 every day.

A bit of history

The series goes back to May 2015, when it started life as Office 365 for Exchange Professionals. Over time, the platform expanded, the audience broadened, and the book evolved with it. This year also marks the move from Office 365 for IT Pros to Microsoft 365 for IT Pros. The name changed, but the focus did not. We still cover the services and workloads administrators, architects, and technologists rely on.

I joined the writing team in 2024. What stood out to me from day one is that this is not a traditional technical book. Most books age the moment they are published. This one does not. We update it every month and keep tracking the constant stream of changes across Microsoft 365. That evergreen model, combined with real-world experience, is what makes this book stand out. It is written for people who manage Microsoft 365 daily and need the most up-to-date content.

What you get

The bundle now consists of four books, each focusing on a specific area:

  • Microsoft 365 for IT Pros is the core book. It covers the Microsoft 365 ecosystem from an administrative perspective, including identity, Exchange Online, SharePoint Online, Teams, OneDrive, and overall tenant management. This edition adds a dedicated AI and Agents chapter covering architecture, licensing, deployment, governance, monitoring, and cost control for Copilot and related technologies.
  • Automating Microsoft 365 with PowerShell is the PowerShell / automation book. It focuses on automating Microsoft 365 with PowerShell and Microsoft Graph, providing practical examples you can apply in real-world environments.
  • Microsoft Purview for IT Pros is a new standalone book. It covers compliance and data governance, including data lifecycle management, eDiscovery, data loss prevention, information protection, and communication compliance.
  • Power Platform for IT Pros is the 2nd new standalone book. It focuses on the administration and governance of the Power Platform, including environments, Dataverse, solutions, application lifecycle management, and platform security through policies and controls. It also covers scenarios for Power Apps, Power Automate, AI Builder, and Copilot Studio.

Splitting the content into separate books allows for more depth and focus, while making the core book easier to consume and maintain. And for those who need it, each companion book is available separately, offering the same monthly updates for that book throughout the subscription.

Who this is for

Tenant administrators, consultants, architects, engineers, and technical leads will get the most value from this edition. If your job involves Exchange Online, Entra ID, SharePoint Online, Teams, OneDrive, Purview, Power Platform, Copilot, PowerShell, or Microsoft Graph, this set has been designed for you.

Availability

We use Gumroad.com to publish and distribute the books. All books are available in EPUB and PDF formats and can be converted for use on Kindle devices.

You can get the books here:

Challenges of PowerShell Scripting with Microsoft 365

Posted on by
Reply

If you are looking for a way to automate and simplify your Microsoft 365 administration tasks, PowerShell is a great option. However, PowerShell scripting is not without its challenges. Not proactively maintaining code can quickly become an issue because of the changes made to dependencies such as modules, as well as the cmdlets you use.

In an article I wrote for Practical 365, related to the presentation of the same name held at the The Experts Conference 2023 in Atlanta this year, I discuss some of the challenges administrators might encounter with PowerShell scripts. Also, I provide some guidance and point out a few tools that can assist with rewriting or refactoring code, i.e., updating code while keeping its external functionality.

Click here to read the full article on Practical 365.

Hosting MTA-STS policy using GitHub Pages

Posted on by
2

The MTA-STS policy (MTA Strict Transport Security) is to prevent Man-In-The-Middle attacks by publishing authorized mail servers and prevent TLS downgrade attacks (Opportunistic TLS), when both parties support MTA-STS. MTA-STS is easier to implement over DANE with DNSSEC, which is expected to get inbound support in Exchange Online next year. Since I am using WordPress to host this blog, I was looking for ways to host the policy file for MTA-STS at the required location, as hosted WordPress does not offer this possibility.

There is documentation describing how to accomplish this using, for example, Azure Static Web Sites, but this requires an Azure subscription. There are also 3rd parties offering hosted MTA-STS, which are usually not free.

Then I stumbled upon the possibility of using a custom domain with GitHub pages, which can be used for this. So, here is a quick write-up on how to host your MTA-STS policy file on GitHub using GitHub Pages. This process could also be used when needed for hosting other files on GitHub.

Hosting MTA-STS Policy using GitHub Pages

Start by creating a new repository in GitHub. You can name it anything you want, but for the sake of the example, I called it mta-sts. Make sure it is public.

Next, we must create an empty file called .nojekyll in the repository. This file will instruct GitHub not to build pages, and just serve your files. So, Add file > Create new file, enter .nojekyll as Name your file and Commit changes.

Now, create the policy file that needs to be named mta-sts.txt in the .well-known folder file, select Add file > Create new file and enter .well-known/mta-sts.txt as the name of your file. This will also create the required folder. In the contents field, paste your policy. For example, the MTA-STS policy file when using only Exchange Online for receiving e-mail could look something like this:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

When done, commit your changes to store the policy file on GitHub. For more information on the MTA-STS policy file definition, click here.

Next, we need to enable GitHub Pages for this repository. Go to Settings, and select the Pages tab. Under Branch, select the branch you want to publish, eg. main, and press Save. Note that GitHub Pages are served using a valid 3rd party certificate, which satisfies one of the requirements for MTA-STS.

New options should now appear on the GitHub Pages settings, one of which is Custom domain. If you decided to use a custom domain in the previous step, enter it here, eg. mta-sts.contoso.com, and click Save.

GitHub will start to check DNS for the presence of this domain. Time to head over to your ISP portal, and create the required records in DNS.

First, if you used a custom domain for hosting the MTA-STS policy, create a CNAME mta-sts record for your domain pointing to <user>.github.io or <org>.github.io, e.g.

mta-sts.contoso.com CNAME 3600 user.github.io

Next, create the DNS TXT _mta-sts record to indicate MTA-STS support, e.g.

_mta-sts.eightwone.com TXT 3600 v=STSv1; id=202310041637

Note that you need to update ‘id,’ usually with timestamp yyyymmddhhmm, whenever you make changes to the policy. This indicates to MTA-STS supporting hosts there has been a change on your end.

You are now set. After DNS some time for DNS to propagate changes, you can start verifying your configuration by browsing https://mta-sts.contoso.com/.well-known/mta-sts.txt, which should return your policy file without any certificate prompts. You can verify DNS and policy access using websites like MxToolbox or PowerDMARC. The example below was generated using EasyDMARC:

TLS Reporting

In addition to setting up MTA-STS, you can configure TLS Reporting (TLS-RPT). This will instruct supporting servers to report on TLS usage and mention certificate issues, for example. Note that these are reports on inbound messages, whereas Exchange Online offers information on outbound TLS usage. To set up TLS-RPT, configure a DNS TXT record _smtp._tls and specify a recipient for these reports, e.g.

_smtp._tls.contoso.com TXT 3600 v=TLSRPTv1; rua=mailto:tlsreports@contoso.com

The rua field contains the e-mail address where reports should be sent. You can process these reports in JSON format yourself or have one of the 3rd parties offering this service do this for you. The example below is generated by Dmarcian.

Using PowerAutomate to echo tweets on Mastodon

Posted on by
11

November 22nd, 2022: Updated Flow diagram and updated blog to mention usage of vars for Mastodon host and bearer token.

And now for something completely different: With the recent news around Twitter, many people are having a look at alternatives. One of these is Mastodon, which is an open source platform, using federated identities on a distributed network. In essence, this means there is not a single phone directory but multiple, yet people living in different phone books can interact with each other as if they were residing in one (federation). Only thing is that, apart from your handle, you also need to know your (Mastodon) host where your account lives.

Now, this isn’t a blog on this social media platform, but it is a quick introduction on how to enable API access to your Mastodon account, and how you can leverage that in PowerAutomate. You can then, for example, toot your tweets (on Mastodon, one toots). There is no built-in action for Mastodon in PowerAutomate, so we need to create it leveraging Mastodon’s API, which is fairly simple for this action.

To start, you need a registered Mastodon account as well as PowerAutomate. First, we are going to configure your account in Mastodon for API access by an app. Navigate to Preferences, select </> Development and Click New Application. You now need to enter some details about your application, such as name and site where the calls originate from, e.g.

The Redirect URI field can be left at its default.

At the bottom of the dialog , you need to specify which calls your application is allowed to make by means of Scopes. For this example, we will only post status updates, so we deselect anything checked, and check write:statuses, which will allow us to post status updates. Click Submit.

After submitting, return to your App details page, and you will notice at the top there is now a client key and secret assigned to the app, as well as an access token. This access token is something we need later on, so make note of it or keep the screen open.

Disclaimer: The Premium connector HTTP is used, which might require a covering Per Flow or Per User service plan. When you don’t, you will get a message during import stating that you “do not have a service plan adequate for the non-standard connection”.

In PowerAutomate, import the Flow package TootMyTweet that I published on GitHub here. During import, pick your Twitter connection to use. After importing, You need to edit the flow by choosing Edit, and make the customizations indicated below the overview diagram:

  • In the When a new tweet is posted trigger, change <Your Twitter Handle> in the query to your Twitter handle (or replace with any other query you desire).
  • In the step Initialize MastodonInstance variable, change the value to your Mastodon host, e.g. mastodon.social.
  • In the step Initialize AuthorizationToken variable, change the value to the Access Token you wrote down earlier from the Mastodon app configuration.
  • The body sets the status field to the tweet, after escaping quotes and expanding any URLs shortened by Twitter. For status (and other) API call information, see the Mastodon documentation here.
  • Note that replies are ignored, as context is lost when tooting replies to Tweets.

Save these changes, and do not forget to enable the Flow. Then wait for the first tweet to be automatically echoed on Mastodon.

Note that this of course is far from perfect: We will skip tooting replies (that is what the condition is for), and will do some escaping to prevent formatting issues, but shortened Twitter URLs and embedded images for example, are still shown as (short) t.co links instead of their intrinsic content or location. Improvements or suggestions are always welcomed.

Happy tooting!

The Last Exchange Server

Posted on by
Reply

In the announcement of the most recent set of Cumulative Updates for Exchange Server 2019 and 2016, Microsoft introduced some changes – features if you will – as well, which were received with enthusiasm. An overview of these Cumulative Updates and the features introduced was given in an earlier article. In this article however, I would like to zoom in on one of those features, which also happens to be a popular topic among customers running Exchange Hybrid deployments, “The Last Exchange Server”.

Up to Exchange 2019 CU12 (2022 H1), customers that migrated to Exchange Online were still required to leave Exchange-related components running on-premises. Even today, with all the information published around this topic, I am surprised this still surprised customers. This Exchange server running on-premises is to be used for managing recipients which have their source of authority in Active Directory, leveraging Active Directory Connect to propagate objects to Azure Active Directory and thus Exchange Online. Also, when there is a need to relay messages from applications or multi-functional devices, customers often need to have an Exchange server on-premises to accept these messages, as Exchange is the only supported mail relay product for hybrid deployments.

Click here to read the full article on ENow Solutions blog.