Wednesday, 4 August 2021

Teams Network Assessment Tool (July 2021 Update)

In July of 2021 Microsoft released a new version of their Network Assessment Tool specifically for Microsoft Teams. This supersedes the old version that was originally released for Skype for Business which we were all still using for Teams deployments (until now). I have a front-end GUI that allows you to graph the results in real time using the Skype for Business version of the tool (still available here). The latest version of the tool appears to have had its core code rewritten and updated with Teams in mind. In this post I’ll do a deep dive into the new tool and compare it to its predecessor.


Here's the link for the new Teams Network Assessment Tool: https://www.microsoft.com/en-us/download/details.aspx?id=103017


At this time the Skype for Business Network Assessment Tool is still also available here: https://www.microsoft.com/en-us/download/details.aspx?id=53885


Note: The version discussed in this post is the Teams Network Assessment Tool 1.4.0.0.


The first change from the old tool is that the commands have slightly changed. By default, the previous tool would run a media quality test and report back latency, packet loss, jitter and reorder ratio. In the new tool, its default is to run a connectivity test to all of the Teams relay servers in Office 365, and the media quality check now requires you use the "qualitycheck" flag when you execute the tool. The output of both of the commands is also quite different than it was in the previous Skype for Business version, which will be demonstrated in the following sections. 

 

Relay Check

The relay check is used to ensure that you can successfully reach the Teams relay services within Office 365 from your current location. It’s important that you run this from a subnet that your Teams clients will be connecting from. There’s not a lot of value in running this from your home when the clients are going to be connecting from an office location that will have different networking and firewall configuration.


No command line flags are required when running the relay check. You simply execute the tool from the command line as shown below:

Command Example:

C:\Program Files (x86)\Microsoft Teams Network Assessment Tool>NetworkAssessmentTool.exe

 

Unlike the previous version of the tool, you do not get to see all the addresses that the tool attempts to connect to when using the verbose flag (as there is no verbose flag anymore). What you get now is a port negotiation check with two servers that will confirm connectivity on all of the 3478-3481 and 443 ports. After this, in the background, it does a check to the full list of relays. However it doesn’t print these tests to the command line:


Something that is new here is that it checks all the TURN redirect ports (3478-3481) for the various workloads (audio, video and screensharing). This matters when you have turned on the “Insert QoS Markets for real-time traffic” setting in the Teams Admin Centre. because this setting will make the relays use the full range of ports when enabled. When it is disabled, the Teams clients only connects to port 3478 on relays and doesn't use the extra 3479-3481 ports.

 Teams Admin Centre > Meeting Settings > Insert QoS Markets for real-time traffic:

 


The previous Skype for Business Network Assessment Tool only checked for connectivity to 3478 which means there may well have been issues with the 3479-3481 ports being blocked on the firewall - you couldn’t establish this using this tool.

If you do have a connectivity issue to one of the servers, then you will receive a specific error for that endpoint. Here is an example of what happened when I blocked connectivity to one of the relay servers:

 

You will see in the results here that “Service verification failed” and it tells me that it could not reach the relay server at 52.114.159.101. So - when you run the tool pay careful attention to the output because it doesn’t highlight these errors in red.


Note: If you are testing for a DoD or GCC domain they will have different Relays than the enterprise tenants. In this case you must include a specific FQDN in your config file (NetworkAssessmentTool.exe.config):


Office 365 Endpoint

Recommended Relay FQDN

Worldwide (including GCC)

worldaz.tr.teams.microsoft.com

U.S. Government DoD

tr.dod.teams.microsoft.us

U.S. Government GCC High

tr.gov.teams.microsoft.us


The setting is in the config file under this key:

<!-- Custom FQDN of the relay (VIP) to be used in the relay connectivity and quality checker  -->

<!-- Note that if this value is kept empty, then a default FQDN (from ECS) is used  -->

      <add key="Relay.FQDN" value=""/>

 


Quality Check

The Quality Check feature of the new version of the tool works slightly differently than the previous version of the tool. In the previous version the tool would send 17 seconds worth of media to the cloud and then report back on the result. In the new version the tool will constantly send media to the cloud and report the results in the command line every 5 seconds. By default, it will do this for 5 minutes and then stop. The command for doing a quality check is as follows:


Command Example:

C:\Program Files (x86)\Microsoft Teams Network Assessment Tool>NetworkAssessmentTool.exe /qualitycheck

  


You can see in the output above that the tool doesn't report reorder ratio like it did in the Skype for Business version. You will only get Latency, Jitter and Packet Loss statistics. The tool with each test will also write the results out to a CSV file so that you can review this data over the running period. Using the CSV file you can create your own graphs with Excel or any other graphing application you might prefer.

Something I have noticed with the new Teams tool compared to the previous Skype for Business tool is that it seems to give consistently higher Jitter values than the old version of the tool. I have found these values to be about 30%-50% higher. This may be a result of it calculating the jitter in a different way or because the length of the media sample it is averaging is about one third the length of the previous tool (5 seconds instead of 17 seconds).

When I ran the new and old tool side-by-side on the same machine on a relatively clean network I was seeing Jitter values of about 7ms reported on the old tool and 10-14ms on the new tool. Then when I injected some jitter using a network emulator, I was getting about 30ms of jitter being reported on the new Teams version of the Network Assessment Tool when the old tool was reporting 15ms of jitter. Bear this in mind when using the new tool as the Jitter values will be higher than you might expect. Based on this, I would say it would be difficult to hit Microsoft’s recommendation of under 15ms average for jitter using the new tool. It might be wise to be a little more lenient with the jitter thresholds and say 30ms as the value from the new Teams version of the tool.


 

Media Duration Setting

By default the Quality Checker will run for 5 minutes and output results every 5 seconds. To change the length of time the quality checker will run for you, need to change the MediaDuration setting in the config file (NetworkAssessmentTool.exe.config):

 

<!-- Duration of media flow for the quality checker, in seconds -->

<!-- Note that Ctrl+C can be pressed at any time to stop the quality check -->

      <add key="MediaDuration" value="300"/>

 

 Port Range Settings

An important thing to note here is that you are using non-default port in the Teams Admin Centre > Meeting Settings > Media Ports section (i.e not 50000-50019 for audio) then it’s best that you update the config file (NetworkAssessmentTool.exe.config) to match your configured range. By default, the tool is only checking connections from the Audio range, so if you really want to do testing from your Video and Screensharing range (e.g. you’re having quality issue specifically with Video or Screensharing) then you can expand or change the range to fall into your specific ranges.

<!--default source port ranges (inclusive) for the relay connectivity and quality checker     -->

      <!-- Audio: 50000-50019

           Video: 50020-50039

           VBSS:  50040-50059 -->

      <add key="MinimumSourcePort" value="50000"/>

      <add key="MaximumSourcePort" value="50019"/>

 

QoS Marker Setting

There is a setting in the config file for QoS Marking settings with and Audio or Video setting. This doesn’t appear to do anything in this version of the tool. I've found that in the current version of the tool I get CS5 (DSCP 40) which is a layer 2 precedence of 5 for both "Audio" and "Video" values. This is not what I would have expected, so I'm not sure if this is fully implemented yet.

<!-- UDP QoS Marking is used just for the quality checker -->

<!-- QoS Marking values should be chosen between 'None', 'Audio' or 'Video' -->

<!-- Note that this field does not apply to the relay connectivity checker -->

        <add key="QoSUDPMarking" value="none"/>

 

 

Excel Example Chart

My Network Assessor Tool GUI, that I made for the Skype for Business version of the tool, would create a line graph of each of the values for Latency, Packet Loss, Average Jitter and Reorder Ratio. A similar kind of graph can be achieved with the CSV output of the new tool using Excel. 


Microsoft's recommended values for maximum Latency, Jitter and Packet loss are as follows:  

Metric

Target

Latency (one way)

< 30ms

Latency (RTT)

< 60ms

Burst packet loss

<1% during any 200 ms interval

Packet loss

<0.1% during any 15s interval

Packet inter-arrival Jitter

<15ms during any 15s interval

Packet reorder

<0.01% out-of-order packets

Note: As I mentioned earlier, the new Teams Network Assessment Tool seems to report Jitter as being greater than the previous Skype for Business version of the tool. I would recommend using 30ms as the threshold for Jitter values in this tool.


Using the above settings as threshold values, you can create a chart that automatically highlights all the values that were out of these ranges. Here is an example of a chart created in Excel with this data:

 

Note: With this graph I used the Microsoft recommended 15ms for average Jitter, and as you can see it was quite consistently reporting a value close to or over that value. This is due to the Jitter reporting issue that I mentioned earlier. I believe that you should use a threshold around 30ms with the values reported from the new version of the tool.


There is a little bit of work required to tweak the graph to look like this. To display the red circles around the values that are outside of the threshold, you need to create a few extra columns in the CSV. Here is an example of formula I used to create these columns:

Column Header

Formula (Filled Down)

LossRate-Over

=IF(B2 > 10, B2,NA())

AverageLatency-Over

=IF(C2 > 60, C2,NA())

AverageJitter-Over

=IF(D2 > 30, D2,NA())

 

You then graph all the columns and 3 new columns listed above together, and change the newly calculated columns above to have markers that look like red circles instead of the original coloured dots. There is a little bit of fiddling required to make it look nice, but I’ll leave that your creative side. Here's an example of what I used for the Format of the Data Series:



 

Pass or Fail

In the previous Skype for Business version of the tool shipped with a results analyzer tool that would check your results file to see if it considered the tests to be a PASS or FAIL. It did this by checking if 10% or more of the tests had failed. We can reproduce this quite easily in Excel using the following formula example: 


=IF((((COUNTA(E2:E68) - COUNTIF(E2:E68,"=#N/A")) / COUNTA(E2:E68)) * 100) > 10,"FAIL","PASS" )

 

You need to run this at the bottom of each of the LossRate-Over, AverageLatency-Over, AverageJitter-Over columns that we calculated earlier. If there was over 10% of the attempts failed then it will  display FAIL and if not then it will present PASS. 


 

HTTP Infra Check

There is a new flag in the Teams Network Assessment Tool named "infraconnectivitytest". This offers a HTTP Infrastructure Check, which can be used to check from proxy issues when connecting to Teams web services. When you run the tool with this flag there is very detailed debug level logging that is outputted to the command line:


Amongst all of the debug messages you will see a summary of the connection attempts which looks like this:

==== Summary ====

 

Successful connections to URLs

        CONFIGS         URL

        9/9             'https://go.trouter.teams.microsoft.com/'

        9/9             'https://ic3.events.data.microsoft.com/Collector/3.0/'

        9/9             'https://config.teams.microsoft.com/config/'

        9/9             'https://api.flightproxy.teams.microsoft.com/api/v1/health'

 

Successful connections using ECS configuration

        URLs            CONFIG

        4/4             '{}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":0, "GenericTcpConnect_Version":1, "IPv6_Killswitch_Enabled":0}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":0, "GenericTcpConnect_Version":1, "IPv6_Killswitch_Enabled":1}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":0, "GenericTcpConnect_Version":2, "Proxy_RespectSystemProxy":1, "IPv6_Killswitch_Enabled":0}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":0, "GenericTcpConnect_Version":2, "Proxy_RespectSystemProxy":1, "IPv6_Killswitch_Enabled":1}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":1, "GenericTcpConnect_Version":1, "IPv6_Killswitch_Enabled":0}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":1, "GenericTcpConnect_Version":1, "IPv6_Killswitch_Enabled":1}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":1, "GenericTcpConnect_Version":2, "Proxy_RespectSystemProxy":1, "IPv6_Killswitch_Enabled":0}}'

        4/4             '{"Regular":{"TLS_Force_Full_Handshake":1, "GenericTcpConnect_Version":2, "Proxy_RespectSystemProxy":1, "IPv6_Killswitch_Enabled":1}}'

 
Presumably if connections don't work you will see some errors show up in this list. So keep an eye on the Summary output for any errors.


The Wrap Up

There have been a few nice improvements with this version of the Network Assessment tool from Microsoft. Hopefully, this post has shed some light on what it can do and what has changed from the previous version of the tool. If you have any questions feel free to drop me a comment below.






Read more →

Thursday, 29 July 2021

Microsoft Modern Wireless Headset Review Video

 I posted a video review of the Microsoft Modern Wireless Headset. Here it is:


If you liked the review and are interested in me doing more of them drop a like or comment on the video.



Read more →

Wednesday, 7 July 2021

Skype for Business User Moves to Teams Failing

The migration path for Skype for Business users to Teams is a well-trodden path. The procedure for doing so involves running the Move-CsUser command from a Skype for Business server and specifying that you want to move the user online. However, when I tried this from a Skype for Business 2015 pool the other day, I ran into some new errors… I hadn't seen these combination of errors before and it was unclear exactly what the problem was as the commands were correct. Here are some examples of the errors I was seeing:


Errors Included (when using OAuth method):

 

VERBOSE: CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com

Confirm

Move-CsUser

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

VERBOSE: Validating parameters for move operation.

VERBOSE: Calculating new server information for user [sipfed.online.lync.com].

VERBOSE: Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.

VERBOSE: Initializing source external move endpoint.

VERBOSE: Creating target external move endpoint.

VERBOSE: Validating the hosted migration override URL provided:

[https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc].

VERBOSE: Retrieving AuthorizationServiceUri and ClientId.

Move-CsUser : Hosted Migration Service (https://adminau1.online.lync.com/HostedMigration/HostedMigrationService.svc/OAuth_Bearer) did not return expected status code from request for WWW-Authenticate header.

At line:1 char:1

+ Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.onli ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (CN=Roger Hybrid...teamslab,DC=com:OCSADUser) [Move-CsUser], MoveUserException

    + FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet

 

When moving using credential Auth method:


 

PS C:\Users\Administrator.MYTEAMSLAB> Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams -Credential $cred -HostedMig

rationOverrideUrl 'https://admin1a.online.lync.com/HostedMigration/hostedmigrationService.svc' -Verbose -Confirm:$False

VERBOSE: CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com

VERBOSE: CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com

VERBOSE: Validating parameters for move operation.

VERBOSE: Calculating new server information for user [sipfed.online.lync.com].

VERBOSE: Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.

VERBOSE: Initializing source external move endpoint.

VERBOSE: Creating target external move endpoint.

VERBOSE: Validating the hosted migration override URL provided:

[https://admin1a.online.lync.com/HostedMigration/hostedmigrationService.svc].

VERBOSE: Retrieving web ticket URL.

VERBOSE: Retrieving live id token.

Move-CsUser : The underlying connection was closed: An unexpected error occurred on a send.

At line:1 char:1

+ Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.onli ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (CN=Roger Hybrid...teamslab,DC=com:OCSADUser) [Move-CsUser], WebException

    + FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet

 

 

From this we have a WWW-Authentication header error and an underlying connection issue error depending on the type of credentials used. These errors went a long way to telling me nothing about what was causing this issue. When all else fails, lets have a look at Wireshark and do some packet peeping. The packets don’t lie and they showed that I was receiving a RST back from Office 365 right after my Client Hello was sent:


 

This immediately made me think that there was some kind of client/server negotiation failing in the TLS connection. So what changed recently with TLS in Office 365? hhhmmm, how about TLS 1.0 and TLS 1.1 being disabled??

As it turns out that was indeed the issue. My server was relatively old and had not been updated to have TLS 1.0 and 1.1 disabled on it. The next question was what could I do to work around this issue?

A classic move from PowerShell which I hoped would work in this case is using the .Net ServicePointManager to control the TLS version used in a PowerShell session. I tried this using the following command:


[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

 

Translation: Use the Transport Layer Security (TLS) 1.2 security protocol for this session.

 

After this I ran a regular OAuth move and it worked!  

$url="https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc"

Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams -HostedMigrationOverrideUrl $url -UseOAuth -BypassAudioConferencingCheck –Verbose

 

PS C:\Users\Administrator.MYTEAMSLAB> Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams -HostedMigrationOverrideUrl

$url -UseOAuth -BypassAudioConferencingCheck -Verbose

VERBOSE: CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com

 

Confirm

Move-CsUser

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

VERBOSE: Validating parameters for move operation.

VERBOSE: Calculating new server information for user [sipfed.online.lync.com].

VERBOSE: Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.

VERBOSE: Initializing source external move endpoint.

VERBOSE: Creating target external move endpoint.

VERBOSE: Validating the hosted migration override URL provided: [https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc].

VERBOSE: Retrieving AuthorizationServiceUri and ClientId.

VERBOSE: Retrieving OAuth token.

VERBOSE: Initializing source external move endpoint.

VERBOSE: Validating user [sip:Roger.Hybrid@myteamslab.com] online, for on premises to online move.

VERBOSE: Validating user [sip:Roger.Hybrid@myteamslab.com] locally on premises, for on premises to online move.

VERBOSE: Validating read-write permissions on local Active Directory.

VERBOSE: Invoking begin move for user [sip:Roger.Hybrid@myteamslab.com].

VERBOSE: Setting resource data for user [sip:Roger.Hybrid@myteamslab.com].

VERBOSE: Completing move for user [sip:Roger.Hybrid@myteamslab.com].

VERBOSE: Re-homing user [sip:Roger.Hybrid@myteamslab.com] on the source.

VERBOSE: Re-homing user [sip:Roger.Hybrid@myteamslab.com] on the target.

 

There you go. Problem solved!


The Wrap Up

Things are constantly changing in Office 365. Stay on your toes because there can always be something new lurking that can make your migrations fail. Hopefully this helps some of you avoid disaster in your migration! Till next time, keep on migrating.




Read more →

Monday, 3 May 2021

Message Centre to Teams using Power Automate

 This post is made to accompany the YouTube tutorial video here: 

Watch the video to see the configuration in real time! All the steps have been documented in black and white here for your reference.

Note: You will need to have Power Automate licencing in order to run this flow. For more info on Power Apps (including Power Automate) trial licences go here: https://docs.microsoft.com/en-us/powerapps/maker/signup-for-powerapps


Configure API Access:

Before creating the Power Automate flow you first need to create an application registration within Azure AD to allow for authentication and access to the Microsoft Message Centre API.

During this process there are specific values that you will need to take note of in order to provide values for the Power Application connection. These are the TenantID, ClientID,  SecretID which will be generated when you create an App Registration within Azure AD.


Step 1: Setup API Access for the Power Automate Flow

a) Log into the Office 365 Admin Center as a Global Administrator, click Admin Centers in the left-hand menu, and click Azure Active Directory. Alternatively, you could log into http://portal.azure.com with your Office 365 administrator account.


b) In the Azure Administration Console, click Azure Active Directory, and under Manage click App Registrations.


c) Click the "+ New Registration" button:


d) Enter any name for your App such as MessageCentreAPI (must be a minimum of 4 characters):


g) Click the Register button at the bottom of the panel.


h) Once the App has been created, several IDs will be shown for your App.  The "Application (Client) ID" represents the ClientID you need for the flow. The Directory (Tenant) ID is the TenantID that you will also need for the flow.  Copy and save that value to use in your Flow.



i) Click the Certificates and Secrets menu item. Then click "New client secret"



j) In the Add Client Secret screen, enter any name for your key (maximum 16 characters) and select a Duration, after which it will expire (This is an added security feature as you don’t want secrets floating around forever).  Then click Save.


Once saved, the key (or SecretID in our case) will be displayed in the value field. 

Important: The Azure portal will only display the SecretID, at the time when it is initially generated.  You cannot navigate back to this page and retrieve the SecretID again later.



Copy and save that value to use in our Power Automate Flow. Be sure to keep your ClientID and SecretID saved privately and securely. 


Step 2: Grant Required Permissions to Your App

Once you have created the App and saved the ClientID and SecretID, you need to grant permissions to the app so it can access the Message Centre API.  You do this in the Azure portal using the following steps:

a) In the Settings page for your App, click the API Permissions menu item:


b) You will see a default Graph API User.Read permission there. Delete this as you don’t need it:


c) Click Add a Permission:

d) Select Office 365 Management APIs and click Select


e) Select Application Permissions


f) Select the “ServiceHealth.Read” permission:


g) Click Add Permissions

h) Once the permissions have been configured you will still see a warning notification in the Status column because admin consent hasn't been granted yet. Click the “Grant admin consent for <tenant name>” button:


i) Once you have granted consent you will see that the Status has been updated to Granted for <your tenant>:




Step 3: Create Flow from Template:

Within the existing Office 365 templates there is an excellent starter flow that does much of what you need to do. This is called “Email me a weekly summary of Office 365 message center notices” (which really rolls off the tongue):



When you initially open this template it will look like this:



This is a great start but you need to make some changes to make this work the way you need for this scenario. Here is an overview of what you are going to do to each of these components:




 

Step 4: Make changes to the existing template

First thing you need to do it edit the Recurrence time to be 1 day instead of 1 week.


Edit the “Get Office 365 messages” node. Select the “Show Advanced Options” to see all the values that you can edit. In here you need to add the Tenant ID, Client ID and Secret that was created in Azure AD in Step 1.



 Parse Subscribed Services

The original "Parse subscribed services" node from the original template is fine to use without editing. However, it doesn’t have the Category row in it that the Message Centre usually displays (plan for change, stay informed, etc), so this needs to be added:


The schema ends up looking like this:

{
    "type": "object",
    "properties": {
        "value": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "AffectedWorkloadDisplayNames": {
                        "type": "array"
                    },
                    "AffectedWorkloadNames": {
                        "type": "array"
                    },
                    "Status": {},
                    "Workload": {},
                    "WorkloadDisplayName": {},
                    "ActionType": {},
                    "AffectedTenantCount": {},
                    "AffectedUserCount": {},
                    "Classification": {},
                    "EndTime": {},
                    "Feature": {},
                    "FeatureDisplayName": {},
                    "Id": {},
                    "ImpactDescription": {},
                    "LastUpdatedTime": {},
                    "MessageType": {},
                    "Messages": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "MessageText": {
                                    "type": "string"
                                },
                                "PublishedTime": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "MessageText",
                                "PublishedTime"
                            ]
                        }
                    },
                    "PostIncidentDocumentUrl": {},
                    "Severity": {},
                    "StartTime": {},
                    "Category": {},
                    "Title": {}
                },
                "required": []
            }
        }
    }
}

 

Filter Array:

The filter array provided in the template has one filter for looking for the Message Type equaling Message Center. For this daily digest we don’t want to see all the messages but instead we want to see only those from the last day. To do this we will add another filter that only allows messages from the previous day. In this case I am using the last 25 hours to ensure that there is no gap between when a message was added and when the daily reoccurrence fires. To do this click on the Edit in Advanced Mode button and paste in one of the filter options below:


There are two choices on this filter. The first is to only list new items to the list and the second is to list new and updated items.

The filter for new items only for the previous 25 hours looks like this:

@and(equals(item()?['MessageType'], 'MessageCenter'),greater(item()?['StartTime'], addHours(utcNow(), -25)))

The filter for new and updated items for the previous 25 hours looks like this:

@and(equals(item()?['MessageType'], 'MessageCenter'),greater(item()?['LastUpdatedTime'], addHours(utcNow(), -25)))

Choose which ever one suits your needs better.


Conditional – If Statement

After we have filtered the array down it could be that we find that there are no messages. In this case rather than post an empty table we can instead have some text to tell us that there was not messages. To do this create a Condition and check the length of the array. If the array is 0 in length then send the message and if it’s not then continue processing the array.



The expression used here is to check the length of the Filter_array output:

length(body('Filter_array'))

 

If YES

If Yes then send a message “You can relax, there were no new Message Centre message today!”:



If NO

This section will contain the rest of the steps to generate the table and post it. The "If no" section is going to end up looking like the screenshot below. Follow the next steps to create this part of the flow:


 

Create HTML Table

Edit the Create HTML table from the original template to make the values equal those shown below (or you can select the table items that interest you):



In order to get a text list of the Affected Workloads for each Message Centre post you need to split the array and convert it to a string. You do this with the “join” expression:

join(item()?['AffectedWorkloadDisplayNames'],', ')

 

 Compose

Add a new Compose node. This will be used to make some edits to the HTML used in the table.


The expression is expanded in the Expression editor window:


Note: The way the expression pop over is displayed depends on how big your window is. So if it doesn't look like this then expand your window to see all the goodness.


In this compose block we give the HTML table a border to make it look better in Teams. To do this you create an expression where you replace the table tag with a table tag that has a border.

replace(body('Create_HTML_table'),'<table>','<table border="2">')

 

Compose 2


In order to make the table more pretty we give each of the cells 10 pixel padding around it.

replace(outputs('Compose'),'<td>','<td style="padding:10px;">')

 

Compose 3


Finally we make the table super pretty by making the header purple and have white text.

replace(outputs('Compose_2'),'<th>','<th style="padding:10px; background-color:#464EB8; color:white;">')

 

Teams Message

When editing the Teams message text ensure that you're in HTML editing mode and not the plain text editing mode. After doing that you want to enter the following HTML and under the Advanced section add a title (e.g. Daily Message Centre Update):


The HTML:

<html>

<body>

<p>&nbsp</p>

@{outputs('Compose_3')}

</body>

</html>


After doing this you will be done. Delete any remaining nodes that were left over from the initial template and test the flow. 


Daily Digest:

Here is an example of what the output should look like in the designated Teams channel: 



If there are no messages for that day you should see the following message posted in the channel:




Logic Apps


If you have Azure with consumption billing in place then you can also build this same flow and run it for under 1 cent per day using Logic Apps! 




This is a great option if you don't already have Power Automate licencing in Office 365. The one difference is that Logic Apps do not have the template that we used to build the Power Automate version from so there are a couple of extra steps you need to do to build some of the steps. It should be pretty straight forward to figure out based on the information already provided in the Power Automate flow. Here is an example that I built and tested in Logic Apps:




The Wrap Up


Taaa Daaaa, there you have it. Fun times with Power Automate. The great bonus here is that you and your team can now discuss and add conversations around these daily updates to further dig into areas that might be of interest to your business or customers. This can lead to valuable discussions about these changes that are persisted for future review. Enjoy!



Read more →

Popular Posts