Lets Exchange

Exporting Log Analytics Logs with Logic App or Power Automate

noreply@blogger.com (Nuno Mota) — Tue, 21 Mar 2023 13:04:00 +0000

For many years, all my PowerShell scripts kept a log of all their actions in a local file stored in the same folder where they ran, or in a file share so my colleagues could access the logs for troubleshooting. Nowadays, with some of those scripts running in Azure Automation, this is not really an option.

Some of these scripts in Azure Automation that don’t run too often, keep a monthly log in a SharePoint Online library. When they run, they download their current month’s log file locally (this is done using the Temp folder, $env:TEMP, which provides 1GB of temporary disk space while the runbook runs), do whatever they need to do while at the same time logging their actions against the local copy of the log file, and, once complete, upload the new log file to SharePoint overwriting the existing log.

However, for scripts that run very frequently, this might not be a suitable solution. For these, I tend to use a Log Analytics workspace where I log all the scripts’ actions. This is a great way to store logs because:

It’s easy to write log entries in it;
It’s easy to run queries against these logs using Kusto Query Language (KQL);
We can retain the logs at no charge for up to 31 days (or 90 days if Microsoft Sentinel is enabled on the workspace), and with the Basic Logs we only pay £0.524 per GB in terms of ingestion;
It’s easy to give my colleagues access to the logs.

For one particular solution I have, some of the users don’t have access to Log Analytics and wouldn’t really know how to use it if they did. As such, I started thinking about how to export these logs into CSV format so they could easily analyse them if needed. My first thought was to use another PowerShell runbook that would export these logs weekly or even monthly. If it’s easy to ingest logs into Log Analytics using its API, exporting them can’t be that hard. But then, why not use Power Automate or a Logic App to do this? It should be quicker to implement and, hopefully, less prone to issues/failures. After some research, I found the Azure Monitor Logs connector, which allows us to build workflows that retrieve data from a Log Analytics workspace or an Application Insights application in Azure Monitor!

This Azure Monitor Logs connector replaces the Azure Log Analytics connector and the Azure Application Insights connector. It provides the same functionality as the others and is now the recommended connector for these queries.

Connector Limits

Before we start configuring our workflow, it’s important to keep in mind the following connector limits:

Max query response size: ~16.7 MB (16 MiB);
Max number of records: 500,000;
Max connector timeout: 110 seconds;
Max query timeout: 100 seconds;
Visualisations in the Logs page and the connector use different charting libraries and some functionality isn't available in the connector currently.

The connector may reach these limits depending on the query you use and the size of the results. If that happens, you must adjust the workflow recurrence to run more frequently and/or with a smaller time range.

Actions

As to the connector actions, it can perform two things:

Run query and list results returns each row as its own object. We can use this action when we want to work with each row separately, or when we want to export the logs to CSV format, for example. This is the one I will be using;
Run query and visualize results returns an HTML table, a pie chart, time chart, or a bar chart depicting the query result set.

Logic App

First, we need to define our trigger. In my case, I will be exporting the logs once a week. As such, under, Start with a common trigger, I select Recurrence:

As I will be running this workflow every Monday morning at 7:00, I configure my trigger like this:

Since I want to search and export Log Analytics logs for the past 7 days, I create two variables that define the start and end of my search. The start will be last Monday (inclusive, meaning >=) and the end will be when the workflow runs, which is also a Monday (but this time, excluding the current day, or <). Each variable is defined as follows:

SearchStart: formatDateTime(addDays(utcNow(), -7), 'MM/dd/yyyy')
SearchEnd: formatDateTime(utcNow(), 'MM/dd/yyyy')

Every time I create a new Power Automate flow or Logic App workflow, I like testing every step as I go along creating them. I believe this makes it easier to ensure everything works as expected and reduce the time troubleshooting any possible issues down the line. So, let’s see what we have so far:

As we can see, SearchStart is the Monday from one week ago, and SearchEnd is today, also a Monday. All good so far!

Next, we click on + New step, search for the Azure Monitor Logs action, and select Run query and list results:

We need to select the Subscription, Resource Group, Resource Type, and Resource Name for our Log Analytics workspace. As to the search query, I will be using the query below that searches the logs using the two variables we created earlier. Notice the >= and < used in the search, which allow us to search from Monday to Monday without duplicating results during each export.

As to Time Range, we need to set this to a value equal or higher than the amount of time we are searching our logs. In this example, I am searching for 7 days’ worth of logs, so I could set this to Last 8 days. However, because we are defining our time range in the query itself, we can simply set this to Set in query.

GlobalRelay_CL

| where DateTime_t >= datetime(@{variables('SearchStart')}) and DateTime_t < datetime(@{variables('SearchEnd')})

| sort by DateTime_t desc

| project DateTime_t, Type_s, Message

If we run our workflow at this stage, we can see that the query is correctly using our SearchStart and SearchEnd variables, and that we are getting log entries returned from Log Analytics! 😊

Now that we have our results, we use the Data Operations action to take the output from our search and create a CSV table:

The From is our data source which, in this case, is the value that gets passed from the Run query and list results action, so that’s what I select. As for Columns, we can leave it to Automatic as I don’t need to map them to a different column name for example.

If we test this step, we should see the log entries that we retrieved from Log Analytics previously, now in a CSV format instead of JSON:

Our final action is to save this data into an actual CSV file. In my case, this will be stored in a SharePoint library, so I search for the Create file SharePoint action:

Next, I specify the Site Address that will store the file, the Folder Path, the File Name, and the File Content. For the file name, I am using the following expression to dynamically generate a name based on the last date of logs the file contains, which is yesterday (Sunday). For the current example, the file will be named “LogExtract_20230319.csv”.

concat('LogExtract_', string(formatDateTime(addDays(utcNow(), -1), 'yyyyMMdd')), '.csv')

Lastly, the File Content is simply the Output from our Create CSV table action, so that’s what we select from Dynamic content:

Running a final test, we can see that the file was successfully created!

If I check our SharePoint library, the file is there with all the data I expected 😊

Error Checking

The workflow seems to work great, but it’s always good practice to include error-checking for any actions that might fail. For example, what if the workflow fails to retrieve the entries from Log Analytics for some reason? To account for this, we can go to our Run query and list results action, and add a parallel branch:

In this new branch, I will send myself an email stating the export has failed. This is just a basic example, and you should include as many details as possible regarding the error itself, the stage at which the workflow failed, etc.

The only thing left to do is to ensure this branch only runs in case of a failure. To do that, we click on the “...” next to our action title, select Configure run after, unselect is successful, and select has timed out and has failed:

Update-ModuleManifest is not recognized as the name of a cmdlet in Azure Automation

noreply@blogger.com (Nuno Mota) — Mon, 20 Mar 2023 16:51:00 +0000

The other day I was moving my PowerShell scripts in Azure Automation to a new Automation Account in a different Azure Subscription. For one of them that connects to Exchange Online through an Azure App Registration, I received the following error when I tried to test it (in the new automation account):

'The term 'Update-ModuleManifest' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.'

It turns out the problem was easy to fix. While on the original automation account I was still using version 2.x of the ExchangeOnlineManagement module, in the new one I am using v3.1.0. Usually this wouldn’t be an issue at all, but clearly the new Exchange module requires the Update-ModuleManifest cmdlet, which is part of the PowerShellGet module that I did not have installed. I found this out by searching for the cmdlet in the Module Gallery:

So, all I had to do was install the PackageManagement module, as PowerShellGet depends on it, and then the PowerShellGet module. All working now!

Trigger Power Automate Flow from a PowerShell script to send an email alert

noreply@blogger.com (Nuno Mota) — Thu, 02 Mar 2023 11:18:00 +0000

Proper error checking, logging, and alerting are essential for any production script. In terms of alerting, whenever my PowerShell scripts fail to perform a certain task, they send me an email alert with the failure error message. I typically do this through a Try/Catch block: I put whatever I need to make sure gets executed successfully inside the Try statement and, if that fails to run for whatever reason, I use the Send-MgUserMail Microsoft Graph PowerShell SDK cmdlet inside the Catch statement to send me the $_.Exception or $_.Exception.Message information related to the cause of the failure.

When my scripts run on-premises, they also use an on-premises Exchange server to send the email alert if the Send-MgUserMail cmdlet fails. However, not all environments have an on-prem Exchange presence (or a separate non-Microsoft method of sending emails). Furthermore, connectivity to on-prem might not even be an option if the script is running in Azure Automation for example (if not running in Hybrid Worker mode, of course).

For these scenarios, what I tend to do is use either a Power Automate Flow or an Azure Logic App that gets triggered by an HTTP request sent by the script which, in turn, sends the email alert.

One thing to keep in mind with Power Automate is that a cloud flow that has no successful triggers will expire and be turned off after 90 days of inactivity (the creator and co-owners are notified by email). This applies when the following licenses are used: 90 days for Free, Trial, Community, and Microsoft 365 Plans. As such, you might want to consider using either an Azure Log Apps, or purchasing a standalone Power Automate license to ensure your flow is not turned off due to inactivity.

Creating the flow

To start, we must first define our trigger. In this case, we use the When an HTTP request is received trigger which, unfortunately, is a premium connector:

As you can see from the screenshot below, the URL is only generated once we save the flow, which we will do shortly. First, we need to define the JSON schema, which will tell the trigger what our POST request will include:

The easiest way is to click on Use sample payload to generate schema and provide an example of what we will be sending in our HTTP POST request. For this example, I will be sending the email alert subject and body so the flow can use that data in the email it will be sending. To do this, I provide a sample JSON payload as follows (in the name/value pair, only the name is important here):

As my alerts are always sent only to me, I am not specifying a recipient. However, if you want to use this flow to send emails to different recipients, you can easily add another field for this by regenerating the JSON schema like we just did. Once we click Done, Power Automate generates our body JSON schema for us:

Next, we search for the Send an email (V2) action so we can send our email. Here, I am using Office 365 Outlook connector as I am using Exchange Online in an enterprise environment. You can obviously use any other connector, such as Gmail or Outlook.com for example.

After defining who the email will be sent to, as soon as we click on the Subject field, the popup box on the right comes up and we can immediately see the Subject and Body dynamic outputs from our previous step (our trigger). These “variables”, which we defined in our schema, will contain whatever we send in the HTTP POST request, assuming the request is correct and includes these fields.

We add each one to its correct place, configure any other options we want for our email, like Importance, and we are done:

Once we save our flow, the URL gets generated, and we can retrieve it:

Testing the flow

We are now ready to test our flow. Since it will be triggered by a normal HTTP POST request, there are many methods we can use. A very popular one is cURL. Since I primarily use PowerShell, let’s see how we can trigger this flow using a native PowerShell method. For this, we have two options (besides the old school .Net objects, like System.Net.WebClient): Invoke-WebRequest and Invoke-RestMethod.

Without going into much detail, Invoke-WebRequest is better at dealing with straight HTML results, while Invoke-RestMethod is much better at dealing with XML and JSON results (it automatically turns XML/JSON responses into PowerShell objects for example).

To keep things simple for this test, let’s do the following:

Save the flow’s URL in a variable called $URL;
Generate our JSON payload with the email subject and body, and save it in a variable called $postBody. The body supports HTML, so we can highly customise our email;
Use Invoke-RestMethod to send an HTTP POST request to our flow URL with our JSON payload. It is crucial that you set the ContentType parameter to application/json, otherwise it will not work.

Obviously, you should add error checking for the Invoke-RestMethod call, but I am trying to keep it simple for testing purposes.

If all is working as expected, we should receive the email with the correct subject and body as per our JSON. If the POST request does not have the correct fields in the JSON payload, an email will still be sent, but it will likely be blank, depending on if any of the fields were included in the request.

As an additional security measure, I like to add another field to my request, a Secret:

I use this secret like an authentication mechanism: if the POST request does not provide the correct secret, the flow will either not do anything, or send me an email saying that someone else is trying to use it.

For this scenario, where the email is only sent to me anyway, this does not bring much benefit. But if emails are sent to other users, you don’t want them to be a victim of a phishing attempt because you did not secure the URL of your flow. Remember that anyone that knows the URL will be able to trigger the flow! Obviously, in this case, they would also need to know the fields being used, but it is always good practice to limit the exposure and reduce the risk.

To do this check, I added a Condition step that checks if the Secret output from the POST request matches the actual secret:

In the end, the flow looks like this:

Monitoring Azure AD Connect Sync times using Power Automate

noreply@blogger.com (Nuno Mota) — Wed, 03 Aug 2022 12:03:00 +0000

For hybrid/federated environments, Azure AD Connect is a crucial service. Azure AD Connect Health provides invaluable information such as alerts, performance monitoring, usage analytics, and other information, but sometimes we need some flexibility on what gets alerted, how, and when.

By default, Azure AD Connect performs a delta sync every 30 minutes. However, what if something happens and it hasn’t been able to perform a sync for 5h? For large organisations, this can be a huge issue as it will impact a variety of services, such as the onboarding of new staff, changes made to groups, changes made to Office 365 services, etc.

In this post, I will show a way of using Graph API to monitor the time Azure AD Connect last performed a sync so we can get an alert when this goes above a specified threshold.

Since we are using Graph API, you will need an Azure App Registration with Organization.Read.All application permissions (check here for other permissions that also work). Once we have our app registration in place, we use the get organization method to retrieve the properties and relationships of the currently authenticated organisation.

If you want to use PowerShell, this is extremely easy with the new SDK. All you have to do is run the following (simplified for brevity reasons):

Import-Module Microsoft.Graph.Identity.DirectoryManagement

Connect-MgGraph

(Get-MgOrganization -OrganizationId "xxxxx-xxxx-xxxxx” -Property OnPremisesLastSyncDateTime).OnPremisesLastSyncDateTime

In this post, however, I’m going to show how to do this, including the alerting, using Power Automate. The first step, after creating a new flow of course, is to schedule it to run at a frequency we desire. In my case, I am running it every 2h because I want to be alerted whenever a sync hasn’t happened in over 2h:

Next, we need to be able to query Graph API, and for that, we need an OAuth token. There are multiple ways of doing this in Power Automate, so feel free to use whatever method you prefer if you already have one. For the method I have been using lately, first we need to initialise three variables that will contain our Azure tenant ID, the ID of our Azure app registration, and its secret:

Now we send an HTTP POST request to https://login.microsoftonline.com/$TenantID/oauth2/token in order to retrieve our token. In the request, we need to pass our app registration details. Again, there are multiple ways to achieve the same, below is the method I’ve been using:

If all goes well, we should now have a valid OAuth token that we can use to query Graph API. Save your flow, test it, and make sure you don’t get any errors. You should see the following in the run history: a status code of 200, and the token details in the OUTPUTS section.

Now that we know our flow works successfully in retrieving an OAuth token, we create a new step where we parse the JSON that gets returned by the previous step. This is because we only need the access_token information (listed at the bottom of the previous screenshot). To do this, we use the Parse JSON action of the Data Operation connector. Under Content, we use the Body from the previous step, and under Schema, you can use the following:

{
    "type": "object",
    "properties": {
        "token_type": {
            "type": "string"
        },
        "expires_in": {
            "type": "string"
        },
        "ext_expires_in": {
            "type": "string"
        },
        "expires_on": {
            "type": "string"
        },
        "not_before": {
            "type": "string"
        },
        "resource": {
            "type": "string"
        },
        "access_token": {
            "type": "string"
        }
    }
}

We can now retrieve the information we want! At the most basic level, we issue a GET request to the following URL: https://graph.microsoft.com/v1.0/organization/our_tenant_id

However, this will return a lot of information we don’t need, so we ask only for the onPremisesLastSyncDateTime by using $select:

Like before, we need to parse the JSON that gets returned so we can more easily use the information retrieved:

For the Schema, you can use Graph Explorer to run the same GET request. Then, copy the Response preview and use it as your sample in Generate from sample.

That will generate the following Schema you can use to parse the JSON:

{
    "type": "object",
    "properties": {
        "@@odata.context": {
            "type": "string"
        },
        "onPremisesLastSyncDateTime": {
            "type": "string"
        }
    }
}

We now have all the information we need. I suggest you test your flow once more to make sure everything is working as expected. If it is, you should get the following:

Although INPUTS and OUTPUTS seem identical, by parsing the JSON we now have an onPremisesLastSyncDateTime dynamic property we can use in our flow, something we don’t get without parsing the JSON:

The next step is to check when the last sync happened. Keeping in mind that the returned date/time is in UTC format, we can use the following formula to check if onPremisesLastSyncDateTime is less than (aka older) the current UTC time minus 2h. If it is, then we know the last successful sync happened over 2h ago and we send an alert.

Simply copy-paste the following formula in the first field of you Condition (unfortunately it’s no longer possible to edit conditions in advanced mode):

less(body('Parse_JSON_-_onPremisesLastSyncDateTime')?['onPremisesLastSyncDateTime'],
addminutes(utcnow(), -120))

If the result is no, then a sync happened less than 2h ago, so we can successfully terminate the flow. Otherwise, we can send a Teams notification (or email, or whatever method you prefer):

In this example, I am posting a Teams message to a group chat. For some reason, Power Automate keeps adding unnecessary HTML code even when I write the code myself… Here is the code I am using:


<p>Last Azure AD Connect Sync was <span style="color: rgb(226,80,65)"><strong>@{div(sub(ticks(utcNow()),ticks(body('Parse_JSON_-_onPremisesLastSyncDateTime')?['onPremisesLastSyncDateTime'])),600000000)}</strong></span> minutes / <span style="color: rgb(226,80,65)"><strong>@{ div(sub(ticks(utcNow()),ticks(body('Parse_JSON_-_onPremisesLastSyncDateTime')?['onPremisesLastSyncDateTime'])),36000000000)}</strong></span> hours ago (@{body('Parse_JSON')?['onPremisesLastSyncDateTime']} UTC)!</p>

This code produces the following message:

But what are those two weird formulas? That’s how we calculate the difference between two dates and times:

div(sub(ticks(utcNow()),ticks(body('Parse_JSON_-_onPremisesLastSyncDateTime')?['onPremisesLastSyncDateTime'])),600000000)

First, we get the current date/time in ticks by using utcNow():

ticks(utcNow())

A tick is a 100-nanosecond interval. By converting a date/time to ticks, we get the number of 100-nanosecond intervals since January 1, 0001 00:00:00 (midnight). By doing this, we can easily calculate the difference between two dates/times. Might sound a bit strange, but a lot of programming languages use ticks.

Then, we subtract the number of ticks for our onPremisesLastSyncDateTime property, which tells us how many ticks it has been since the last sync:

sub(ticks(utcNow()),ticks(body('Parse_JSON_-_onPremisesLastSyncDateTime')?['onPremisesLastSyncDateTime']))

Lastly, because we don’t want the result in ticks but in minutes or hours, we divide the result by 864000000000 so we get the time difference in minutes, or by 36000000000 to get the result in hours.

And there you have it! Now, whenever Azure AD Connect takes over 2h to perform a sync, you will be notified! 😊

Create Calendar Event on all user mailboxes

noreply@blogger.com (Nuno Mota) — Tue, 15 Feb 2022 16:56:00 +0000

The other day I was asked by our HR department if it was possible to create a calendar event on all user mailboxes. They didn’t want to send a “normal” meeting invite to dozens of thousands of users that people would have to accept, reject, or ignore. All they wanted was a simple all-day calendar event that would notify users about this particular event.

In my opinion, this has always been one of those features I don’t know why Microsoft never added to Exchange. I can think of so many cases where this would be so useful for so many organisations, but here we are. I remembered reading about something like this a few years back, but it turned out I was thinking about the Remove-CalendarEvents cmdlet introduced in Exchange 2019 and Online. This cmdlet allows admins to cancel future meetings in user or resource mailboxes, which is great when someone leaves the organisation for example.

So that was not an option. I thought about using Exchange Web Services (EWS). I’ve written quite a few EWS scripts and that was an option. However, it is all about Graph API nowadays, so that was by far the best option. But can this be done using Graph API? Of course it can! For that, we use the Create Event method:

POST /users/{id | userPrincipalName}/events

POST /users/{id | userPrincipalName}/calendar/events

POST /users/{id | userPrincipalName}/calendars/{id}/events

I’ve also written many Graph API scripts and they work great! However, I’ve had to use lengthy functions to get a token, query Graph API, etc., which made these scripts long and complex... However, with the Graph API SDK, this is far from the case! Now it is extremely easy for admins and developers to write PowerShell Graph API scripts! It is really, really straightforward, and no need to rely on HTTP Post requests!

Requirements

You will need to have, or create, an app registration in Azure and use a digital certificate for authentication. This link explains how to easily set this up: Use app-only authentication with the Microsoft GraphPowerShell SDK.

The Graph API permissions required for the script to work are 'Calendars.ReadWrite' and 'User.Read.All' (again, if using the -AllUsers switch). Both of type Application.

With the Graph API SDK, you will need the 'Microsoft.Graph.Calendar' and 'Microsoft.Graph.Users' (if using the -AllUsers switch, more on this later) modules. For more information on the SDK and how to start using it with PowerShell, please visit this link.

Script Parameters

-UsersFile

TXT file containing the email addresses or UPNs of the mailboxes to create a calendar event on.

-ExcludeUsersFile

TXT file containing the email addresses of the mailboxes NOT to create a calendar event on.

Whenever the script successfully creates an event on a user’s mailbox, it saves the user’s SMTP/UPN to a file named 'CreateCalendarEvent_Processed.txt'. This is so the file can be used to re-run the script for any remaining users (in case of a timeout or any other issues) without the risk of duplicating calendar entries.

-AllUsers

Creates a calendar event on all Exchange Online mailboxes of enabled users that have an EmployeeID. This can, and should, be adapted to your specific environment or requirement.

The script does not use Exchange Online to retrieve the list of mailboxes. It retrieves all users from Azure AD that have the Mail and EmployeeID attributes populated.

Script Outputs

The script prints to the screen any errors, as well as all successful calendar entries created.
It also generates a log file named ‘CreateCalendarEvent_Log_date’ with the same information.
Whenever it successfully creates an event on a user's mailbox, it outputs the user's SMTP/UPN to a file named ‘CreateCalendarEvent_Processed.txt’. This is so the file can be used to re-run the script for any remaining users (in case of a timeout or any other issues) without the risk of duplicating calendar entries.
For any failures when creating a calendar event, the script writes the user's SMTP/UPN to a file named ‘CreateCalendarEvent_Failed.txt’ so admins can easily analyse failures (the same is written to the main log file).

Notes

When using the -AllUsers parameter, the script uses the Get-MgUser cmdlet to retrieve Azure Active Directory user objects. I decided not to use Exchange Online cmdlets to keep things simple and because I wanted only mailboxes linked to users that have an EmployeeID. Obviously, every scenario is going to be different, but it should be easy to adapt the script to your specific requirements.

One thing I found, was that running Get-MgUser against a large number of users (in my case, 25000+ users), PowerShell 5.1 was crashing for no apparent reason. Other users on the internet were having the exact same problem when running for a few thousand users. It turns out PowerShell 5.1 default memory allocation will cause the script to crash when fetching large data sets… The good news is that it works great with PowerShell 7+!

The script is slow... When I ran it for 37000+ users, it took approximately 1 second per user. Need to look into JSON batching to create multiple events in one single request.

The script will throw errors in an Hybrid environment with mailboxes on-prem (as they are returned by Get-MgUser). If this is your case, you might want to use an Exchange Online cmdlet instead of Get-MgUser (or get all your mailboxes and then use the -UsersFile parameter).

Script

You can get the script on GitHub here.

Examples

C:\PS> .\CreateCalendarEvent.ps1 -AllUsers

This command will:

Retrieve all users from Azure AD that have the Mail and EmployeeID attributes populated;
Create a calendar event on their mailboxes. The properties of the calendar event are detailed and configurable within the script.

C:\PS> .\CreateCalendarEvent.ps1 -AllUsers -ExcludeUsersFile .\CreateCalendarEvent_Processed.txt

This command will:

Retrieve all users from Azure AD that have the Mail and EmployeeID attributes populated;
Create a calendar event on their mailboxes, unless they are in the 'CreateCalendarEvent_Processed.txt' file.

Unlimited Exchange Online Archiving is no longer Unlimited

noreply@blogger.com (Nuno Mota) — Fri, 01 Oct 2021 08:38:00 +0000

TLDR: Microsoft has added size restrictions to Unlimited Archiving (aka Auto-Expanding Archiving). The change will take effect beginning November 1, 2021. Once this limit takes effect, users will not be able to extend their online archives beyond 1.5TB.

Upcoming Changes to Auto-Expanding Archive

MC288051 · Published 29 Sept 2021 · Last updated 30 Sept 2021

Message Summary

Updated September 30, 2021: We have updated the content below for additional clarity. Thank you for your patience.

We will be removing the word ‘Unlimited’ from our service description and related public documentation for the auto-expanding archiving feature, and instituting a 1.5TB limit for archive mailboxes. This limit is not configurable.

Key points

Timing: This change will take effect beginning November 1, 2021 and is applicable to all environments.
Roll-out: tenant level
Action: review and assess

How this will affect your organization

Once this limit takes effect, your users will not be able to extend their online archives beyond 1.5TB. As currently noted in our documentation, auto-expanding archive is only supported for mailboxes used for individual users or shared mailboxes with a growth rate that does not exceed 1 GB per day. Using journaling, transport rules, or auto-forwarding rules to copy messages to Exchange Online Archiving for the purposes of archiving is not permitted. A user's archive mailbox is intended for just that user. Microsoft reserves the right to deny auto-expanding archiving in instances where a user's archive mailbox is used to store archive data for other users or in other cases of inappropriate use.

If you have previously worked with Microsoft Support to provide exceptions for existing archives exceeding 1.5TB, those specific archives will not be affected by this change. You will not, however, be able to create any new archives that exceed 1.5TB.

What you need to do to prepare

You should check the size of archives in your organization if you are concerned that they might be close to the limit and consider deleting some of the content if you intend to continue adding to the archive. You can use Get-MailboxFolderStatistics to view archive mailbox size.

Exchange Online PowerShell Scripts with Modern Auth

noreply@blogger.com (Nuno Mota) — Wed, 08 Jul 2020 12:47:00 +0000

Auditing and reporting scenarios in Exchange Online often involve scripts that run unattended. In most cases, these unattended scripts access Exchange Online PowerShell using Basic Authentication (username and password). However, basic authentication for Exchange Online Remote PowerShell will be retired in the second half of 2021. As an alternative method, Microsoft has recently announced the Public Preview of a Modern Authentication unattended scripting option. As such, if you currently use Exchange Online PowerShell cmdlets in unattended scripts, you should look into adopting this new feature. This new approach uses Azure AD applications, certificates and Modern Authentication to run non-interactive scripts!

How does it work?

The EXO V2 module uses the Active Directory Authentication Library to fetch an app-only token using the Application ID, Azure Tenant ID, and a digital certificate thumbprint. The application object provisioned inside Azure AD has a Directory Role assigned to it (like Exchange Administrator), which is returned in the access token. Exchange Online then configures the session RBAC using the directory role information that is available in the token.

Configuring app-only authentication

This feature is still in Public Preview and requires version 2.0.3-Preview or later of the EXO PowerShell v2 module (available via PowerShellGallery).

To install the Preview release of the EXO v2 module, run the following command:

Install-Module -Name ExchangeOnlineManagement -RequiredVersion 2.0.3-Preview -AllowPrerelease

If already installed, you can update an earlier version of the of the EXO v2 module by running the following command:

Update-Module -Name ExchangeOnlineManagement -AllowPrerelease

Step 1: Application registration in Azure AD

Go to the Azure AD portal at https://portal.azure.com/ and sign in with your Azure AD account;
Under Manage Azure Active Directory, click View;
Under Manage, select App registrations and then click New registration;
In the Register an application page that appears, configure the following settings:

Name: Enter something descriptive.
Supported account types: select Accounts in this organizational directory only (Microsoft).

When you are finished, click Register;
In my case, I called it Exchange Online PowerShell:

Step 2: Assign API permissions to the application

Next, we need to assign it permissions to manage Exchange Online as an app. An application object has the default permission User.Read. For the application object to access Exchange Online resources, it needs to have the application permission Exchange.ManageAsApp. API permissions are required because they have consent flow enabled, which allows auditing (directory roles do not have consent flow).

Select API permissions;
In the Configured permissions page that appears, click Add permission;
In the flyout that appears, scroll down to Supported legacy APIs and select Exchange:

In the flyout that appears, click Application permissions;
In the Select permissions section, expand Exchange and select Exchange.ManageAsApp and then Add permissions:

Back on the Configured permissions page, click Grant admin consent for “tenant name” and select Yes in the dialog that appears. Ensure the permissions have been granted (green tick):

Step 3: Generate a self-signed certificate

There are multiple ways to create a self-signed X.509 certificate. You can use the Create-SelfSignedCertificate script or the makecert.exe tool from the Windows SDK for example. Personally, I found the easiest way to be the New-SelfSignedCertificate PowerShell cmdlet. The following example creates a self-signed certificate and places it in my personal certificate store:

New-SelfSignedCertificate -Subject “ExO-PS-Nuno” -KeyExportPolicy “Exportable” -CertStoreLocation cert:\CurrentUser\My -Provider “Microsoft Enhanced RSA and AES Cryptographic Provider”

While we are here, take note of the certificate’s thumbprint as we will need it in the final step.

It might be obvious, but I should mention that the certificate has to be installed on the user certificate store of the computer where you want to connect to Exchange Online from.

Next, export the certificate using the format .CER (we will need it in the next step):

Step 4: Attach the certificate to the Azure AD application

In the Azure AD portal under Manage Azure Active Directory, click View;
Under Manage, select App registrations;
On the App registrations page that appears, select your application;
Under Manage, select Certificates & secrets;
On the Certificates & secrets page, click Upload certificate:

In the dialog that appears, browse to the self-signed certificate you created in the previous step, and then click Add:

The certificate is then uploaded and added to the application:

Step 5: Assign a role to the application

One thing to note with this method is the lack of RBAC controls. We simply cannot take advantage of the granular controls Exchange offers with RBAC... Instead, what the service principal can and cannot do is determined by the role it is assigned in the Azure AD portal. We can play with the roles and actions assigned to these role groups, but those changes will obviously affect anyone assigned the same role.

Azure AD has more than 50 admin roles available. For app-only authentication in Exchange Online, the following roles are currently supported:

Global administrator
Compliance administrator
Security reader
Security administrator
Helpdesk administrator
Exchange administrator
Global Reader

In the Azure AD portal under Manage Azure Active Directory, click View;
Under Manage, select Roles and administrators;
Select one of the supported roles. On the Assignments page that appears, click Add assignments;
In the Add assignments flyout, find and select the application, and then click Add:

Our application now has Exchange administrator rights:

Step 6: Connect to Exchange Online PowerShell

The final step is to connect using our certificate’s thumbprint. To do this, we run the following cmdlet:

Connect-ExchangeOnline -CertificateThumbPrint “EAB240A72B05FBC980D1259FD21AE099D530F4AF” -AppID “3c2025f6-xxxx-xxxx-xxxx-xxxxxxxxxxxx” -Organization “xxxxxx.onmicrosoft.com”

And there you go! 😊

If you don’t want to install the certificate, you can actually connect using the local .pfx certificate instead:

Connect-ExchangeOnline -CertificateFilePath “C:\Users\nuno\Documents\Exo-PS-Nuno.pfx” -AppID “3c2025f6-xxxx-xxxx-xxxx-xxxxxxxxxxxx” -Organization “xxxxxx.onmicrosoft.com”

Important Considerations

As any other action performed in Exchange Online, any changes we do via this new method still results in them being captured in the Admin audit log and, in turn, in the Unified Audit log in Office 365. A downside I should highlight, is that any actions performed using this method will list the application as the user performing the action. As such, it might be a good idea for any admin to have their own application so that actions can be correctly audited and tracked.

Another important thing to keep in mind when using this new method, is that its authenticating flow against Azure AD is not subject to Conditional Access policies and MFA enforcement. While this can be great as it allows us to enable automation, you must take extra care to secure your app details and certificate’s private key, as anyone who gets their hands on them can easily reuse them from anywhere...

Restoring Deleted Items from Exchange as an Admin

noreply@blogger.com (Nuno Mota) — Wed, 08 Jul 2020 07:13:00 +0000

The Get/Restore-RecoverableItems PowerShell cmdlets have been available for some time now in Exchange Server 2016/2019 and Exchange Online environments. These allow admins to restore deleted items from user mailboxes such as in the following example:

Restore-RecoverableItems nuno@domain.com -FilterItemType IPM.Note -SubjectContains “New Joiner – John Doe” -FilterStartTime “20/06/2020 12:00:00 AM” -FilterEndTime “21/06/2020 11:59:59 PM”

Items are restored to the original folder location if the information is available for the item. If the information cannot be found, the item is restored to the default folder for the item type (Inbox for messages, Calendar for meetings and appointments, and so on).

What this post is mainly about, however, is the fact that admins can now do the same from the preview version of Exchange Admin Center (with the new UI)!

Important: please note that in order to use these cmdlets and the method described below, you need to be assigned the Mailbox Import / Export permission which, by default, no one is assigned.

To get started, go to the Exchange Admin Center and click on Try it now to access the preview version:

Alternatively, you can use the following link to get to it directly: https://admin.exchange.microsoft.com/#/mailboxes

Next, select the user you want to recover deleted items for and then look for the Recover deleted items link on the user property page:

The new Recover deleted items UI will show up and automatically list the latest 50 recoverable items:

We can easily search for the items we are interested in by subject, type, or folder type:

After clicking Apply filter, our results are reduced to recoverable items containing the subject line “azure” which were deleted within the past 30 days. Once we find the item(s) we want to recover, we simply select it/them and click on Recover deleted items:

Once recovered, a green banner will appear indicating all items have been successfully recovered:

All done! 😊

Exchange LUN disappeared after reboot

noreply@blogger.com (Nuno Mota) — Fri, 26 Jun 2020 09:37:00 +0000

After rebooting an Exchange 2013 server to complete the installation of a security update, 2 LUNs just disappeared:

Looking in Disk Management their Status was Failed:

The LUNs were offline, and after manually bringing them online everything was back to normal.

There had been some previous work done on these LUNs in order to expand them and, for some reason, the default Windows policy to make SAN disks offline was applied (it assumes VMware disks are SAN disks).

After changing the policy to make “new” disks online by default, the issue didn’t happen again:

How to set OWA Language and Time zone using PowerShell

noreply@blogger.com (Nuno Mota) — Fri, 26 Jun 2020 08:53:00 +0000

When a user first logs on to Outlook Web App (OWA), he/she gets prompted to set their language and time zone:

Can we, as administrators, pre-set these for users or change them after they have been set, for example? Of course! To do this, we use the Get/Set-MailboxRegionalConfiguration cmdlet:

The two parameters we are interested for this scenario are:

Language: specifies the language setting, such as en-us, that would apply for the mailbox;
TimeZone: specifies the time zone, such as Pacific Standard Time, that the mailbox in the specified region uses. The default value is the time zone setting on the server.

Let us say, for example, that we want to set everyone’s mailbox to American English and Pacific time. To do this, all we need to run is:

Get-Mailbox –ResultSize Unlimited –Filter {RecipientTypeDetails –eq "UserMailbox"} | Set-MailboxRegionalConfiguration –Language en-US –TimeZone "Pacific Standard
Time"

How to Change Exchange EAC Language

noreply@blogger.com (Nuno Mota) — Fri, 26 Jun 2020 08:47:00 +0000

When we first login to the Exchange Admin Center (EAC), we are greeted with the language selection screen and time zone. But how do we change EAC’s language after that? The answer is to use Outlook Web App (OWA). Once you have logged into OWA, select the cog icon in the top right hand corner and then click Options:

Next, go to settings in the options menu, and on the right hand menu select regional. Now edit the language and time zone settings to what you want as these settings also apply to the EAC:

But what about for environments where administrators do not have mailboxes? How do they change EAC’s language if they do not have access to OWA? In this case, you can specify the language you want to use in the URL itself. For example, for American English, add ?mkt=EN-us to the EAC’s URL: https://mail.domain.com/ecp?mkt=EN-us

This works for both on-premises Exchange 2013 and above, and Office 365.

How to Disable Microsoft Stream

noreply@blogger.com (Nuno Mota) — Thu, 25 Jun 2020 09:44:00 +0000

As an Office 365 Global Admin, you can prevent some or all users in your organisation from being able to use Stream. This is typically done in cases where employees are already using Office 365 Video or if Stream has not been approved by all parts of your organisation.

When a first user from any organisation signs-up for Microsoft Stream using their corporate credentials, Microsoft Stream service is registered as an application in the organisation's Office 365 tenant. The license is automatically assigned to the user who signed up. There are additional licenses available for the IT admin to assign to other users in the organization without them going through the sign up process.

Important: as an admin, you can unlicense users from the Office 365 admin center. However, even though you might have removed Microsoft Stream license from a user, they have the option to sign-up via a free trial and get access to your organisation's Stream portal.

To turn off Microsoft Stream for everyone, follow these steps:

As an Office 365 Global Admin, log in to the Azure portal;
In the Azure Active Directory (AAD) section, click Enterprise Application, and then in the Manage section, click All Applications;
Change the filters to Show All Applications with All Application Status, and then click Apply;
Search for Microsoft Stream Service from the list of applications, or search by the GUID 2634dd23-5e5a-431c-81ca-11710d9079f4 for Microsoft Stream Service:

Click the Microsoft Stream Service application, and then under Manage, click Properties;
Set Enabled for users to sign-in flag to No;
Click Save:

You have now blocked access to all users for Stream. When a user now tries to access Stream, they will receive the following error message:

RecipientNotFoundPermanentException when migrating a mailbox to Exchange Online

noreply@blogger.com (Nuno Mota) — Wed, 24 Jun 2020 10:10:00 +0000

The other when migrating a mailbox from an on-prem Exchange 2013 environment to Exchange Online, I was faced with a RecipientNotFoundPermanentException error with the message “Error: Cannot find a recipient that has mailbox GUID '39c970e4-4869-47ee-b9af-f6fd6264ee0a'.”

These were the details for the mail user in Exchange Online (notice the ExchangeGuid attribute):

And these were the details for the mailbox on-premises:

As you can see, the ExchangeGUID was the same! And where was that '39c970e4-4869-47ee-b9af-f6fd6264ee0a' GUID coming from?!

After much troubleshooting, I ended up logging a support ticket with Microsoft. According to the engineer, “this issue is caused due to multiple mailbox shards”. Unfortunately, he wouldn’t go into details as apparently it is all secret stuff... But he ran some diagnostics to resolve the issue, and after a few minutes all was well with the world again!

Block emails delivered directly to user@domain.onmicrosoft.com or user@domain.mail.onmicrosoft.com (MX Bypass)

noreply@blogger.com (Nuno Mota) — Wed, 24 Jun 2020 09:34:00 +0000

Let’s assume I have my mailbox in Exchange Online with an email address of nuno@domain.com. External users can send emails directly to nuno@domain.onmicrosft.com (the tenant’s default domain) or to nuno@domain.mail.onmicrosoft.com (typically used in Hybrid environments) and they will be delivered to my mailbox. This is because these two managed domains are fully managed by Microsoft and have internet-routable MX records:

Not a big problem for “pure” Office 365 organizations as these emails are still subject to Exchange Online Protection (EOP) policies such as anti-spam and anti-malware. However, this is a problem for organizations that use a 3^rd-party service for message hygiene. In this scenario, these emails would completely bypass the 3^rd-party and all the security measures it enforces.

There are a few solutions out there that rely on mail flow (transport) rules to either reject or redirect these emails back to the 3^rd-party provider, but these never quite worked for me... The main reason is that transport rules are processed post onresolveMessage event and when this happens the email address for the recipient changes to the PrimarySMTPAddress which has the domain.com suffix.

The solution I ended up implementing was slightly different. I created an Inbound Partner Connector, set the sender domain address space to *, and restricted it to only accept emails if the sender presents the certificate I have configured on my on-prem Hybrid servers (you can also restrict it to your on-prem or 3^rd-party IP addresses). The following procedure assumes that we have a setup in which we have executed the Hybrid Configuration Wizard (HCW) successfully (which would have created the required connectors for mail flow).

First, we run the following command to get a list of inbound connectors configured by HCW. If you have Hybrid across multiple Exchange Organizations, then you’ll see more than one entry.

$onpremorg = Get-OnPremisesOrganization | Select OrganizationGuid, InboundConnector | Where {$_.InboundConnector -ne $null}

$onpremorg

If the Inbound Connector was configured by the HCW, then the attribute TlsSenderCertificateName will map either to the domain name included in the subject or subject alternate name attribute of the 3^rd-party certificate used, or it will contain the details of the certificate.

Next, we create the inbound partner connector using the following command:

New-InboundConnector -Name “Block Direct Delivery” -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $onpremorg[0].InboundConnector).TlsSenderCertificateName -RestrictDomainsToCertificate $True -RequireTls $True

Once this connector is in place, any external senders that try to email nuno@domain.onmicrosft.com or nuno@domain.mail.onmicrosoft.com will receive the following NDR:

Emails sent to Exchange Online mailboxes routed through the on-prem Exchange servers, will always use the Inbound connector created by the HCW, while service emails like notifications from Teams, SharePoint Online, etc., will use the default connectors.

If you use a 3^rd-party service for message hygiene but your emails flow directly from the 3^rd-party to Exchange Online, you can still use this method, but instead of restricting the connector to a certificate using the RestrictDomainsToCertificate parameter, you can restrict it to the IP(s) of your 3^rd-party service by using the RestrictDomainsToIPAddresses parameter.

Azure AD Connect “An error occurred while connecting to the state store: attempted to perform an authorized operation”

noreply@blogger.com (Nuno Mota) — Mon, 22 Jun 2020 08:54:00 +0000

The other day, while trying to enable an optional feature on a staging Azure AD Connect server, I came across the following error:

The Trace log, located at C:\ProgramData\AADConnect, had the following:

[06:42:08.604] [  1] [INFO ] MicrosoftOnlinePersistedStateProvider.Save: saving the persisted state file
[06:42:08.605] [  1] [INFO ] MicrosoftOnlinePersistedStateProvider.UpdateFileProtection: updating file protection from the persisted state file: C:\ProgramData\AADConnect\PersistedState.xml, isAddProtection: False
[06:42:08.607] [  1] [ERROR] PerformConfigurationPageViewModel: Caught exception when connecting to persisted state store.
Exception Data (Raw): System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
   at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)
   at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)
   at System.Security.AccessControl.FileSystemSecurity.Persist(String fullPath)
   at Microsoft.Online.Deployment.Types.PersistedState.MicrosoftOnlinePersistedStateProvider.UpdateFileProtection(String fileName, Boolean isAddProtection)
   at Microsoft.Online.Deployment.Types.PersistedState.MicrosoftOnlinePersistedStateProvider.Save(PersistedStateContainer state)
   at Microsoft.Online.Deployment.Types.PersistedState.MicrosoftOnlinePersistedStateProvider.SetStateElements(IEnumerable`1 elements)
   at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.PerformConfigurationPageViewModel.SavePersistedState()

Looking at the properties of the PersistedState.xml file, located in the same directory, I noticed it was set to Read-Only:

And that Everyone only had read access (the special permissions only block deletion) with no other users specified:

Comparing this to a “healthy” server, the configuration was the same. Nonetheless, I temporarily gave the service account full access to the file, and it worked!

Collecting Microsoft Teams Logs

noreply@blogger.com (Nuno Mota) — Tue, 02 Jun 2020 08:11:00 +0000

Microsoft Teams has three different types of logs, which get stored on different locations.

Web Logs
Consists of most Teams client activity.

Windows: to capture logs, open Teams and press CTRL+ALT+SHIFT+1 in the client, and the logs will be downloaded to %downloads%\MSTeams Diagnostics Log.txt
MAC: press Command+Option+SHIFT+1 in client to download logs to Downloads\MSTeams Diagnostics Log.txt

Desktop Logs
This log has most information about framework and bootstrapping information, app bootstrap process, plugin initialization, update management and SSO/ADAL Sign in information.

Windows: %appdata%\Microsoft\Teams\logs.txt
MAC: ~/Library/Application Support/Microsoft/Teams/logs.txt

Media Stack Logs
This log has media connectivity related information.

Windows: %appdata%\Microsoft\Teams\media-stack
MAC: ~/Library/Application Support/Microsoft/Teams/media-stack

Microsoft Teams Mobile client (iOS):
To collect log on Teams mobile client, open Microsoft Teams app -> Settings -> Report an issue. A new email will open with log.txt attached.

Gather Microsoft Teams Statistics using Graph API

noreply@blogger.com (Nuno Mota) — Sun, 01 Mar 2020 00:14:00 +0000

This script uses Graph API to gather statistics regarding Microsoft Teams.

IMPORTANT:

You will need to have, or create, an 'app registration' in Azure and create a 'client secret';
The app registration will need the following API permissions to Graph API: 'Group.Read.All' and 'User.Read.All', both of type 'Application'.

The script gathers and exports the following stats for each team:

Team: the display name of the team;
Description: the team's description as set by its owner;
Email: the team's email address;
CreatedOn: the date and time the team was created;
RenewedOn: the date and time when the team was renewed;
Visibility: if the team is 'Private' or 'Public';
Owners: the number of owners;
OwnerNames: the display name of all the team's owners;
Members: the number of members;
Channels: the number of channels for the team;
ChannelNames: the display name of all the team's channels.

To call the script, simply run:

.\GetTeamsDetails.ps1

Exchange Online Meeting Room Statistics - Graph API

noreply@blogger.com (Nuno Mota) — Sun, 01 Mar 2020 00:02:00 +0000

A few years ago I wrote an article named "Exchange Meeting Room Statistics" about a script to gather statistics regarding Exchange meeting room usage for MSExchange.org (now techgenix.com). For this script to work, we have to give ourselves FullAccess to the meeting rooms’ mailbox, add them into our Outlook profile, and then use an Outlook COM Object to connect to Outlook and gather this information. Far from ideal, especially when trying to analyse dozens of rooms!

A couple of years after, I wrote a new version that uses Exchange Web Services to gather the same information, plus some further stats. However, this script wasn't very reliable with Exchange Online as it would work in some environments, but not in other.

I have finally written this newer version, specifically targeted at Exchange Online only, this time using Graph API!

IMPORTANT:

To analyze a particular meeting room, specify one or more primary SMTP addresses in the format: "room1@domain.com, room2@domain.com". Alternatively, analyze all meeting rooms by using the "-All" switch;
You will need to have, or create, an 'app registration' in Azure and user digital certificate for authentication (you can update the script to use 'client secret' instead);
The app registration will need the following API permissions to Graph API: 'User.Read.All', 'Calendars.Read', and 'Place.Read.All', all of type 'Application';
Maximum range to search is 1825 days (5 years);
You can enter the dates in the format "22/02/2020", "22/02/2020 15:00", or in ISO 8601 format such as "2020-02-22T15:00:00", or even "2020-02-22T15:00:00-08:00" to specify an offset to UTC (time zone).

The most basic way of running the script is as follows (more examples in the script itself):

.\Get-MeetingRoomStats_GraphAPI.ps1 -All -From "01/01/2020" -To "01/02/2020"

The script gathers and exports the following stats for each meeting room for the given date range:

RoomName: the display name of the meeting room (when using -All). When using -RoomListSMTP, this will be the room's SMTP address;
RoomSMTP: the SMTP address of the meeting room;
From: the start of the date range to search the calendar;
To: the end of the date range to search the calendar;
totalMeetings: the total number of meetings;
totalDuration: the total number of minutes for all meetings;
totalAttendees: the total number of attendees invited across all meetings;
totalUniqueOrganizers: the number of unique meeting organizers;
totalUniqueAttendees: the number of unique attendees;
totalReqAttendees: the total number of required attendees;
totalOptAttendees: the total number of optional attendees;
Top5Organizers: the email address of the top 5 meeting organizers, and how many meetings each scheduled;
Top5Attendees: the email address of the top 5 meeting attendees, and how many meetings each attended;
totalAllDay: the total number of 'all-day' meetings;
totalAM: the total number of meetings that started in the morning (this excludes all-day meetings);
totalPM: the total number of meetings that started in the afternoon;
totalRecurring: the total number of recurring meetings;
totalSingle: the total number of non-recurring meetings (single instance/occurrence).

How to disable Office 365 self-service purchase

noreply@blogger.com (Nuno Mota) — Thu, 21 Nov 2019 13:53:00 +0000

I am sure by now you have heard or read about Microsoft plans to allow Office 365 users to make self-service purchases for the Power Platform. This created such a storm of critics and complaints that Microsoft postponed the introduction of this feature to January 14, 2020. Additionally, it has finally released a way for admins to block such feature.

“Beginning January 14, 2020, self-service purchase, subscription, and license management capabilities for Power Platform products (Power BI, Power Apps, and Power Automate) will be available for commercial cloud customers in the United States. Self-service purchase gives users a chance to try out new technologies and lets them develop solutions that will ultimately benefit their larger organizations. This capability will not be available to tenants in the US that are government, nonprofit, or education, at this time. Central procurement and IT teams will have visibility to all users buying and deploying self-service purchase solutions through the Microsoft 365 admin center, and will be able to turn off self-service purchasing on a per product basis via PowerShell.”

On November 19, Microsoft updated their self-service FAQ and stated that “Admins can also control whether users in their organization can make self-service purchases. For more information see Use AllowSelfServicePurchase for the MSCommerce PowerShell module.”

The MSCommerce PowerShell module is now available on PowerShell Gallery. The module includes a PolicyID parameter value for AllowSelfServicePurchase that lets you control whether users in your organization can make self-service purchases.

You can use the MSCommerce PowerShell module to:

• View the default state of the AllowSelfServicePurchase parameter value — whether it's enabled or disabled;

• View a list of applicable products and whether self-service purchase is enabled or disabled;

• View or modify the current setting for a specific product to either enable or disable it.

To use the MSCommerce PowerShell module, you need:

• A Windows 10 device;

• Administrator permission for the device;

• Global or Billing Admin role for your tenant.

Install the MSCommerce PowerShell module

Download the MSCommerce PowerShell module from the PowerShell Gallery. To install the MSCommerce PowerShell module with PowerShellGet, run the following command:

Install-Module -Name MSCommerce

Import MSCommerce into the PowerShell session

After you install the module, import it into the PowerShell session by running the following command:

Import-Module -Name MSCommerce

Connect to MSCommerce

Finally, connect to the PowerShell module with your credentials. This command connects the current PowerShell session to an Azure Active Directory tenant. The command prompts you for a username and password for the tenant you want to connect to. If multi-factor authentication is enabled for your credentials, you use the interactive option to log in.

Connect-MSCommerce

View details for AllowSelfServicePurchase

To view a description of the AllowSelfServicePurchase parameter value and the default status, based on your organization, run the following command:

Get-MSCommercePolicy -PolicyId AllowSelfServicePurchase | FL

View a list of self-service purchase products and their status

To view a list of all available self-service purchase products and the status of each, run the following command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

View or set the status for AllowSelfServicePurchase

After you view the list of products available for self-service purchase, you can view or modify the setting for a specific product. To get the policy setting for a specific product, run the following command:

Get-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N

To enable the policy setting for a specific product, run the following command:

Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N -Enabled $True

To disable the policy setting for a specific product, basically preventing users from purchasing licenses themselves, run the following command:

Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KP0N -Enabled $False

To disable all three at the same time, you can use the following command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | ForEach {Update-MSCommerceProductPolicy -PolicyId $_.PolicyID -ProductId $_.ProductID -Enabled $False}

MapiExceptionMessagePerFolderCountQuotaExceeded

noreply@blogger.com (Nuno Mota) — Sun, 15 Sep 2019 15:19:00 +0000

The other day during a mailbox migration of an on-prem Exchange 2013 mailbox to Exchange Online, I came across the following error:

Error: QuotaExceededException/MapiExceptionMessagePerFolderCountQuotaExceeded: Error: Cannot save changes made to an item to store. --> MapiExceptionMessagePerFolderCountQuotaExceeded: Unable to save changes.

The message was due to a folder in the user’s mailbox which had almost 1,500,000 items in it. The problem is that Exchange Online enforces a maximum number of 1M messages per mailbox folder limit (across all Exchange Online plans). New messages can’t be delivered or saved in a folder when this limit is reached.

There is also a warning for number of messages per mailbox folder. Once a folder in Exchange Online reaches 900,000 items, Exchange Online sends a warning message to the mailbox owner. When this quota is reached, warning messages are sent once a day.

To check which folder(s) in a user’s mailbox is causing this, you can use the Get-MailboxFolderStatistics cmdlet:

Get-MailboxFolderStatistics "user" | % {If ($_.ItemsInFolder -ge 1000000) {Write-Host "Folder with $("{0:N0}" -f $($_.ItemsInFolder)) items: '$($_.FolderPath)'" -ForegroundColor Red}}

It is also crucial to check other limits before starting to sync mailboxes, like mailbox size limit, folder limit, and so on.

Hope it helps!

The onboarding move could not be created because user ‎is already being moved

noreply@blogger.com (Nuno Mota) — Sun, 31 Mar 2019 17:43:00 +0000

When migrating mailboxes to Exchange Online in a Hybrid environment, you might encounter the following error:

PS C:\> Get-MigrationUser user@domain.com | FL

Identity            : user@domain.com
BatchId             : Pilot Migration 1
MailboxEmailAddress : user@domain.com
RecipientType       : MailboxOrMailuser
Status              : Failed
StatusSummary       : Failed
MigrationType       : ExchangeRemoteMove
State               : Failed
WorkflowStep        : DataMigration
WorkflowStage       : Injection
ErrorSummary        : The onboarding move could not be created because user 'User' is already being moved.

If you have already checked all your migration batches (Get-MigrationBatch) and/or all your individual move requests (Get-MoveRequest “user”) and there is absolutely no move request associated with this user, then it is very likely you still have a move request for the user in your on-premises Exchange environment.

So, go to your on-premises environment and remove the local move request for that particular user. This should clear the msExchMailboxMoveRemoteHostName AD attribute. Other attributes related to move requests that you can also check are:

msExchMailboxMoveBatchName
msExchMailboxMoveFlags
msExchMailboxMoveRemoteHostName
msExchMailboxMoveSourceMDBLink
msExchMailboxMoveStatus
msExchMailboxMoveTargetMDBLink

How to Update Office 365 Groups Primary Email Address

noreply@blogger.com (Nuno Mota) — Wed, 06 Feb 2019 17:13:00 +0000

The other day I got asked if it was possible to update the primary SMTP address of multiple Office 365 Groups in one go. It turns out that, for this particular tenant, the default domain was still the tenantname.onmicrosoft.com one, meaning all the groups created until then had an email address of group@tenantname.onmicrosoft.com instead of group@domain.com.

To do this, we have to use PowerShell as it is not possible to change the email address of such group using the EAC.

First, we connect to Exchange Online PowerShell, and then we need to use the *-UnifiedGroup cmdlet.

To retrieve the list of groups that need to be updated, we use the following code:

Get-UnifiedGroup -ResultSize Unlimited | Where {$_.PrimarySmtpAddress -like "*tenantname.onmicrosoft.com"}

To update the primary SMTP address of an Office 365 Group, we use the Set-UnifiedGroup cmdlet with the PrimarySmtpAddress parameter:

Set-UnifiedGroup “Test Group” -PrimarySmtpAddress “test.group@nunomota.pt”

Below you can see that the existing primary email address becomes an alias of the group, so no alias/email addresses are lost:

To do this is a large scale, we can use a script like the following:

Get-UnifiedGroup -ResultSize Unlimited | ? {$_.PrimarySmtpAddress -like "*tenantname.onmicrosoft.com"} | % {
  $smtp = $_.PrimarySmtpAddress
  $newSmtp = $smtp.Split("@")[0] + "@domain.com"
  
  # If all the groups’ email addresses are in the alias@ format, then we can simply use the following instead
  # $newSmtp = "$($_.Alias)@domain.com"

  Write-Host "Updating ""$($_.DisplayName)"" from $smtp to $newSmtp"
  Set-UnifiedGroup $_.Identity -PrimarySmtpAddress $newSmtp
}

Installing Exchange Server 2019 Preview on Windows Server 2019 (Core and GUI)

noreply@blogger.com (Nuno Mota) — Sat, 04 Aug 2018 14:53:00 +0000

Amongst other big changes, such as the lack of the Unified Messaging role from Exchange Server 2019, the biggest announcement has to be the fact that this is the first version of Exchange that can be installed on a Windows Server Core (either 2016 or 2019)!

So, without further ado, let’s look at how we install the Preview version of Exchange 2019 on a Windows Server 2019 Core as well as on a Windows Server 2019 with a GUI (Desktop Experience).

Preparing Windows for Exchange
After downloading the ISO or Hyper-V image from the Windows Insider Preview website, install the OS as you would normally. In this case, I am using Hyper-V server on a Windows 10 machine. After the OS is installed, the first step is to change the default Administrator’s account password:

Once this is done, we can either use SConfig.cmd or PowerShell to configure the server’s name, domain, network and other settings:

To use PowerShell instead, run start powershell from the command line, which will open a PowerShell window:

Using PowerShell, we can use the Get-NetIPAddress cmdlet to retrieve the network adapters on the server, and then New-NetIPAddress and Set-DNSClientServerAddress to configure it. For example:

New-NetIPAddress -InterfaceIndex 5 -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DNSClientServerAddress -InterfaceIndex 5 -ServerAddress “192.168.1.2”

To rename and join the server to the nunomota.pt domain, we could use the following cmdlet:

Add-Computer -DomainName nunomota.pt -NewName EX1 -DomainCredential nunomota\admin

Note that these PowerShell cmdlets can be used to configure both the Core and on the Desktop Experience versions of Windows Server.

Windows Features and Additional Software
We will let Exchange Setup configure the required Windows Features it needs, but there are two we have to install beforehand as they are required for Microsoft UCMA 4.0 and to prepare Active Directory:

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Next, we need to enable file sharing on our Core server, so we can copy some required files to the server. This can be done using the following cmdlet:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=yes

Next, from another workstation, download the following software and copy it over to the server:

Exchange Server 2019 Public Preview - only required for the Core server. For the second server with Desktop Experience, we can simply mount the image through Hyper-V Manager;
Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x64.exe).

To install Visual C++, navigate to the location where you copied the file to, and simply run vcredist_x64.exe:

Now we need to install UCMA (Microsoft Unified Communications Managed API 4.0), which comes in the Exchange 2019 media itself. On the Core server, start by mounting the Exchange ISO file:

Mount-DiskImage C:\full_path\ExchangeServer2019.iso

Once this is done, go to the UCMARedist folder, and run Setup.exe to start the installation:

Finally, restart the server:

Restart-Computer -Force

Exchange Installation (Core)
After restarting the server, re-mount the Exchange ISO image and run an unattended installation as you normally would. We can either prepare Active Directory and the Domains separately or let the Setup do everything. In this case, let’s do everything separately.

First we use the /PrepareSchema switch to extend the Active Directory schema:

Next, the /PrepareAD switch to prepare Active Directory:

Then we use /PrepareAllDomains to prepare all the Active Directory domains:

Finally, we can install Exchange, and all the required OS components, using the same method we are used to with previous versions:

.\Setup.exe /Mode:Install /Roles:Mailbox /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Once the installation completes, we can launch the Exchange Management Shell using LaunchEMS command from the command line:

Done! From here, we can manage this server using a variety of methods such as the Exchange Management Shell, Exchange Admin Center, remote PowerShell, and all the Windows management tools.

Exchange Installation (GUI)
As for the Desktop Experience version of Windows, we can obviously install Exchange unattended, or follow the installation wizard, which is pretty much identical to Exchange 2016:

Once installation has complete, we have the usual links in the Start menu:

We have our Exchange Management Shell:

And the Exchange Admin Center:

From a user perspective, they get the “new” Outlook in the Web :)

Kernel for Exchange Server Recovery - Product Review

noreply@blogger.com (Nuno Mota) — Wed, 18 Jul 2018 15:49:00 +0000

In this product review, we will have a look at version 18.2 of Kernel for Exchange Server from Lepide Software’s sister company, Kernel Data Recovery.

Lepide Software is known company in the IT arena. Its Kernel range of products include popular solutions for data recovery, database recovery, file repair, email migrations, email recovery, and more. Kernel for Exchange Server is primarily an Exchange mailbox database recovery tool. It helps admins easily recover mailbox content (emails, attachments, contacts, calendars, and tasks) after any event of Exchange disruption or corruption. Besides being able to convert an EDB file to PST, it can migrate mailboxes from offline EDB files to a live Exchange environment or even to Office 365 mailboxes (including archive mailboxes and public folders). Some of its features include:

Extraction of mailbox data from inaccessible EDB files to PST;
Extraction of data to MSG, EML, TXT, RTF, or HTML formats;
Migration of mailboxes from offline or online databases to Exchange and Office 365;
Migration from IMAP servers (like Gmail, Yahoo, Hotmail, and GroupWise) to PST, live Exchange Server, or Office 365 mailbox;
Export Office 365 mailboxes to Office 365 mailboxes or PST;
Fully compatible with Microsoft Outlook 2016 & Exchange Server 2016, as well as all prior versions;
In-built backup extractor to recovery EDB files from NT Backup and VERITAS backups.

So let’s start by looking at how we install this tool.

Installing Kernel for Exchange Server

Before downloading and installing Kernel for Exchange Server, make sure your system fulfils the following prerequisites:

Processor: minimum dual-core processor (quad-core recommended);
RAM: minimum 4 GB (8 GB recommended);
Disk: minimum 200 MB free disk space;
Windows Operating System: either 32 or 64-bit of Windows 7 or above, or Windows Server 2003 or above;
Outlook: Outlook 2000 or above;
Exchange: Exchange Server 2000 or above;
Supported Virtual Environments: VMware Server 1.0x (or above), VMware Workstation v6.0x (or above), VMware ESX 4.0 (or above), Hyper-V, and Microsoft Virtual PC 2007.

Start by downloading Kernel for Exchange Server software from this webpage and save it locally. Once you have the installer file, follow these steps:

1. Double-click the Kernel for Exchange Server’s installer file. It will initiate the installation process with the following setup wizard:

2. Click Next to proceed. Read the license agreement carefully and then select I accept the agreement:

3. Click Next to continue to the next dialog box. This will display the wizard to change the destination location:

4. The default installation location is %ProgramFiles%\Kernel for Exchange Server for 32-bit and %ProgramFiles(x86)%\Kernel for Exchange Server for 64-bit Windows OS. You can click Browse to change the location if desired. Once you’re done, click Next;

5. If required, change the location of the shortcuts folder in the Start Menu:

6. Click Next to proceed to the next steps, where you have the option of creating icons in the desktop and Quick Launch bar for easy access:

7. Click Next to proceed;

8. Setup is now ready to start the installation process. Click Install:

9. Once the installation is complete, click Finish to complete the installation process:

10. If you have checked the Launch Kernel for Exchange Server option, then the software’s main screen will appear:

Here we can see that this product has a very clean, modern and easy to use user interface.

Using Kernel for Exchange Server

The first step to use the software, is to select a source from which we want to retrieve/recover data from. This can be any of the following:

· An offline Exchange EDB file;

· A live Exchange environment, from which we can select:

o A single mailbox;

o Public Folders;

o Archive mailbox;

o Multiple mailboxes;

o An Outlook profile to add a single mailbox as a source.

· Gmail, Yahoo, Novell GroupWise, or other email accounts using an existing Outlook Profile;

· Office 365:

o A single mailbox;

o Public Folders;

o Archive mailbox;

o Multiple mailboxes,

o An Outlook profile to add a single mailbox of Office 365 as a source.

Let’s start with a corrupted EDB file and then have a look at Office 365.

EDB Files as a Source

An unmounted and offline EDB file can be added as a source. Kernel for Exchange Server scans the EDB file for possible errors, fixes them, retrieves its data, and then allows us to export it to a PST file or transfer it to another Exchange mailbox for example.

For this test, I have an EDB file in a Dirty Shutdown state:

So, let’s see how Kernel for Exchange Server deals with it. To add it as a source:

1. We start by clicking on Add Source... or on Offline EDB;

2. We select the Offline EDB File option and click Next:

3. There are two ways of adding one or more EDB files: we can select the EDB file manually by clicking on ... and select the location where the EDB file is stored, or we can search for EDB files using the Search button. While scanning EDB files, the temporary scanning data and logs are stored in the Temp Path directory.

4. Next, we must choose between the two types of EDB scanning:

a. Standard Scan should be used when the EDB file is not severely corrupted or if we just want to migrate the data from a working offline EDB file to any destination. If the EDB cannot be recovered using this method, then the software will switch to Deep Scan;

b. Deep Scan is for severely corrupted EDB files, or those very large sized. This scan will take longer but should retrieve most data from the EDB file.

5. In some cases, where the EDB file is severely corrupted, the From field of emails either shows an ambiguous value or are blank. Therefore, it is advised to check the box titled Use message table to get "From" field:

6. Click Next to start the scanning. Once complete, the following dialog box is displayed:

7. Click Finish button to complete the process;

8. After completing the process, the selected offline EDB file(s) is displayed under Source List, together with all the mailboxes it holds:

From here, we can explore the mailboxes in the EDB file and, if Outlook is installed, preview their content, such as calendar entries, contacts, emails, and so on:

Extracting one or more items is straightforward. We simply select the one(s) we want to extract, right-click on them and select one of the desired options:

If we are exporting emails, we can select the location where to export them to, in which format we want those emails saved as, and if we want to keep their folder hierarchy:

Once the process is complete, we are notified:

Exporting to PST

Now that we have access to the data inside the EDB file, we can extract to PST file(s) using two different methods. One way is to click on PST File in order to create a blank PST file as a destination, which we can use to drag-and-drop items into. We select Create New PST File:

Chose a location and a name for it:

And click Next to create it and add it as a Destination:

We now have the EDB file as a Source and our newly created PST as a Destination. As the tip in the main screen suggests, we can now simply drag-and-drop items (be that emails, calendar items, contacts, and so on) from our EDB to our PST file:

The second method allows us to easily export one or more mailboxes to PST. To use this method, we right-click on our source and select Export Mailboxes to PST...:

From here, we can select which mailboxes we want to export, and all of them will have their own PST file:

We can also manually select which folders we want to export for each mailbox. A downside is that, by default, it also extracts all the system folders that are typically hidden from users, and those are generally not needed... We can use the Custom Selected option, which allows us to filter out all the system folders we don’t want to extract and apply that filter to all mailboxes:

Using the Set Filter option, we can easily decide which item types we want to extract, and which ones we want to ignore. We can also filter items based on their creation time. A really good feature indeed.

Once we are happy with our selection(s) and filters, we click Export and the process begins:

Once complete, we get a report stating how many items were exported per folder, if any duplicates were found, and some more details:

Office 365

Office 365 can be used both as a source or as a target. As a requirement, we need an account with the following rights in Office 365/Exchange Online:

· A Global Administrator;

· Full Access permission over all the Office 365 mailboxes we want to work on.

After establishing the connection, we can use Single Mailbox, Multiple Mailboxes, Public Folders, and Archive Folders as sources or targets. We can then export/import data from/to mailboxes in Exchange Online. For example, we can connect to a mailbox on-premises using the Live Exchange option (source), connect to a mailbox in Exchange Online using the Office 365 option, and then migrate the mailbox’s content from on-premises to the cloud. It is also possible to export Office 365 mailbox items to EML, DBX, and PST files.

After selecting Office 365 (Exchange Online) option, click Next:

Select an option to specify what you want to connect to. Either:

1. Connect Single Mailbox;

2. Connect Public Folder;

3. Connect Archive Mailbox;

4. Connect Multiple Mailboxes.

Enter the user name and password of a user account that has full rights over the selected mailbox(s) or public folder(s). The strange thing here, is that we need an Outlook profile (at least when using Outlook 2016) created with the user that has full access to the mailboxe(s) we want to import data into. This means the Use existing outlook profiles option must be selected as Kernel for Exchange Server will use Outlook and a MAPI connection to import data. Since Outlook is used, why do we need to specify credentials and a server name? After all, Outlook will take care of all of that with the profile we must create...

Click OK after you have created the required profile and entered all the mandatory details:

If the tenant has multiple mailboxes, then the wizard shows the list of all mailboxes:

Check the mailbox(s) you want to add as a source or target, and click Next;

All the selected mailboxes are then added (in this case to the target/destination pane):

From here, it’s easy to import data into the mailbox by dragging items from a source like an offline EDB file, a live Exchange mailbox, or even from another Office 365 mailbox.

Conclusion

Although it’s possible to use Kernel for Exchange Server to perform mailbox migrations from an on-premises live Exchange environment to Office 365, for example, it is important to keep in mind that this tool has been primarily designed as an Exchange mailbox database recovery tool. With that in mind, it performs great in that field. It can easily recover data from inaccessible EDB files, and export that data to PSTs or to a myriad of other formats or targets. As a bonus, it is also capable of performing basic migrations, which can come in handy in some situations.

Exchange Online Mailbox Audit Improvements: UpdateFolderPermissions

noreply@blogger.com (Nuno Mota) — Tue, 10 Apr 2018 07:56:00 +0000

A few weeks ago, Microsoft added a new action to the Exchange mailbox auditing: UpdateFolderPermissions. As the name suggests, when this action is being logged, it records changes to folder permissions, be that Owner, Delegates, or Admin.

Microsoft has updated the default mailbox audit configuration to include the UpdateFolderPermissions action. In the following screenshot, we can see that auditing has not been enabled for the ServiceDesk shared mailbox, but UpdateFolderPermissions is part of the default auditing configuration for all 3 access types:

Existing mailboxes that have not deviated from the default configuration will be automatically updated to include the UpdateFolderPermissions action. My own mailbox has had the default auditing settings enabled for a long time, and now UpdateFolderPermissions was automatically added as well:

With mailbox audit configured with this action, we will find records in the audit logs when permissions of folders are added, deleted or modified. These records can be found both in the unified audit log:

Or in the mailbox audit log through the Search-MailboxAuditlog cmdlet.

In the following screenshot, we are searching the mailbox audit logs for the AddFolderPermissions action. Using these logs, we can see that I (LogonType: Owner) used OWA to give ServiceDesk Owner rights to my Clutter folder, and that I used Outlook to give them Reviewer rights to my Archive folder:

Besides AddFolderPermissions, we can also track ModifyFolderPermissions and RemoveFolderPermissions actions: