Teams Tenant Dial Plan Tool

I recently released a tool for configuring Direct Routing within an Office 365 tenant. Its name is the imaginative Microsoft Teams Direct Routing Tool. This tool, whilst allowing you to configure all your PSTN Gateways and Routing, did not allow you to configure the normalisation of numbers that users dial prior to being routed. This step in the process is very important because nearly all users are not going to dial phone numbers in E.164 format. As a result, prior to getting to the E.164 based routing rules we need to do some work to ensure that the numbers dialed have been converted into the right format. The number normalisation in O365 is done by the Tenant Dial Plan policies, which contain normalisation rules. The configuration of these are done using the Skype for Business Online module and bunch of pretty complicated PowerShell that really shouldn’t be inflicted on a regular human being. So to try and avoid this pain, I decided to make a sister tool to my Direct Routing Tool that will allow for simple configuration and editing of these Tenant Dial Plans. This time, in order to ensure that I came up with the most imaginative name possible for the tool, I trekked into the deepest jungles of Peru on a vision quest where after drinking several litres of Ayahuasca came up with the name “Teams Tenant Dial Plan Tool”. Enjoy…

Teams Tenant Dial Plan Tool

The Tenant Dial Plan Tool is a PowerShell based tool that allows you to configure and edit Tenant Dial Plans within Office 365 for use with Microsoft Teams Direct Routing and Calling Plans. This tool is a sister tool to my Microsoft Teams Direct Routing Tool that allows you to configure all the routing for Direct Routing within Office 365. To use the tool, simply open it with PowerShell (with the Skype for Business Online Module installed) and you will be presented with the following GUI and features:

Tool Features

• Log into O365 using the Connect SfBO button in the top left of the tool. Note: the Skype for Business Online PowerShell module needs to be installed on the PC that you are connecting from. You can get the module from here: https://www.microsoft.com/en-us/download/details.aspx?id=39366
• Create/Edit and Remove Tenant Dial Plan policies using the New.., Edit.. and Remove buttons.
• Copy existing Tenant Dial Plans and all their Normalisation rules to a new Tenant Dial Plan.
• Add/Edit Tenant Dial Plan normalisation rules. If the rule you are setting has a name that matches an existing rule, then the existing rule will be edited. If the rule’s name does not match an existing rule then it will be added as a new rule to the list.
• Delete one or all normalisation rules from a Tenant Dial Plan policy.
• Easily change the priority of normalisation rules with the UP and DOWN buttons.
• Test the normalisation rules! Teams currently (at the time of writing this) doesn’t have any normalisation rule testing capabilities. So I wrote a custom testing engine into the tool providing this feature. By entering a number into the Test textbox and pressing the Test Number button, the tool will highlight all of the rules in the Dial Plan that match in blue. The rule that has the highest priority and matches the tested number will be highlighted in green. The pattern and translation of the highest priority match (the one highlighted in green) will be used to do the translation on the Test Number and the resultant translated number will be displayed in the Test Result.

Updates:

• Initial Release 1.00

Note: the Skype for Business Online PowerShell module needs to be installed on the PC that you are connecting from. You can get the module from here: https://www.microsoft.com/en-us/download/details.aspx?id=39366

Download from TechNet Gallery:

DOWNLOAD HERE

Frequently Asked Questions

1. What is the deal with the OptimizeDeviceDialing setting - I can't edit it? 

In order to use the Access Prefix value that you can enter when creating a policy in the tool, a setting in the background called OptimizeDeviceDialing must also be turned on (for more details about what an Access Prefix is, refer to Ken Lasko's post about how they work in Lync). In addition to this, there is some weirdness in the PowerShell commands, which means that after you have set an Access Prefix for a policy you cannot then delete this value. You can only overwrite an existing Access Prefix with another number. When you delete the Access Prefix in the Edit dialog of the tool it will set the OptimizeDeviceDialing setting to FALSE (and leave the existing Access Prefix because it can't delete it). For example, if you already have an Access Prefix configured (as say "0") on a policy and then open the Edit dialog and remove the Access Prefix value like shown in the image below:

... then the result will show as the Access Prefix still being "0" in the main window (due to it not being able to be deleted by PowerShell) but it will update the OptimizedDeviceDialing setting to FALSE so the Access Policy is not used:

The Wrap Up

Well that was one hell of a ride. I think the Ayahuasca has nearly worn off and it's time for me to lie down. Enjoy the tool and remember, kids, don’t drink weird potions in the jungle…

Read more →

Skype for Business 2019 Call Forward Tool

In the July 2019 update of Skype for Business Server 2019 (a release that might also be called CU1 or CU2 depending on if you include a Hotfix release that came about a month earlier) now includes some new PowerShell commands that allow you to centrally control users' call forwarding settings. This functionality used to be available via a tool called SEFAUTIL.exe in the Skype for Business resource kits in previous versions of the server releases. This is obviously great news because this is the functionality that was used all the time in practice by most organisations that I have seen.

The first question is what do we actually get with these new commands? We basically get the ability to do all the things a user can do from the Call Forward settings dialog within the Skype for Business client. This includes adding users to their Team Call Group and Delegate lists as well as setting call forward immediate, unanswered and simultaneous ring.

For more details on using the commands directly, Greig Sheridan has done a nice write up here: https://greiginsydney.com/sfbs-2019-sefautil-in-powershell/

Whilst it’s great to have these commands at our disposal, I still find that there is a learning curve to figuring out which settings and flags to use to achieve the call forward type that you might want in practice. So I thought it would be good to build a GUI for the PowerShell commands that looked exactly the same as the call forward settings screen from the Skype for Business client that we have all been using for many years and understand already. So that’s what I did… Introducing the Skype for Business 2019 Call Forwarding Tool:

Skype for Business 2019 Call Forwarding Tool

Tool Features:

• No learning curve - it works the same as the call forward configuration on the Skype for Business client!
• Get the call forwarding settings for any user on the system.
• Edit team-call groups members.
• Edit delegate members
• Forward calls immediately to another number, delegates or contact.
• Set simultaneous ring to team-call members, delegates, number or contact.
• Control when the settings will apply ("all of the time" or "during work hours in Outlook")
• Set the call forward settings on one or a number of users by selecting them from the user list on the right hand side of the tool.

Updates:

1.00 Initial Release

Download from TechNet Gallery:

DOWNLOAD HERE

Limitations

The PowerShell commands that have been supplied by Microsoft have the following limitations when compared to what can be set in the Skype for Business Client:

• In Delegate and Team-call settings the "ring after" timer can only be set to 0, 5, 10 or 15 seconds, whereas in the Client you can set it from zero to 55 seconds (the maximum value is actually is whatever the unanswered call timer is, minus 5 seconds, which is a maximum of 55 seconds). 
• There is no ability to select which delegates will be able to receive calls. This is represented in the client as a checkbox next to the delegate in the "Call Forwarding - Delegates" dialog. This capability is not available in the PowerShell commands at the moment.

Known Issues

Known Issue 1: Call Forward Unanswered to a Phone Number Issue

There is a bug in Skype for Business Server 2019 July 2019 update when Call Forward Immediate is disabled but Call Forward Unanswered is set to point to a number. This scenario looks like this in the Client:

From PowerShell it looks like this:

Set-CsUserCallForwardingSettings -Identity "sip:john.woods@domain.com" -DisableForwarding -UnansweredToOther "+61395554444" -UnansweredWaitTime 10

Whilst this command will be accepted by the system and look like the data has set correctly within the client the actual Call Forward will not work when you call the Client (ie. instead of the call going to the number it forwards to the user's Voicemail). This is due to a bug in the Set-CsUserCallForwardingSettings command which will hopefully be fixed in the next CU.

Known Issue 2: Call Forward Immediate to Voice Mail Issue

In Skype for Business Server 2019 July 2019 the PowerShell commands do not tell you if the user has Call Forward Immediate to Voice Mail configured. If you run the Get command it will show:

User                             : sip:john.woods@sfb2019lab.com
CallForwardingEnabled            : False
ForwardDestination               :
ForwardImmediateEnabled          : False
SimultaneousRingEnabled          : False
SimultaneousRingDestination      :
ForwardToDelegates               : False
SimultaneousRingDelegates        : False
TeamRingEnabled                  : False
Team                             : {}
Delegates                        : {}
DelegateRingWaitTime             : 0
TeamDelegateRingWaitTime         : 0
SettingsActiveWorkhours          : False
UnansweredToVoicemail            : True
UnansweredCallForwardDestination :
UnansweredWaitTime               : 30

... which looks exactly the same as if there is no Call Forward set at all.

The commands also do not have a flag to allow you to set Call Forward Immediate to "Voice Mail". As a work-around for this, I have implemented the setting of Call Forward Immediate using a special SIP Address format. The SIP Address of a user's Voice Mail can be represented as their SIP Address with the following parameters after it ";opaque=app:voicemail". So, in order to forward to Voice Mail, the tool currently uses this method which the Client also respects and displays correctly as a Forward to Voice Mail. When this issue is fixed I will update the tool accordingly.

The Wrap Up

Forward away my friends! Forward away!

Read more →

Microsoft Teams Direct Routing Tool

If you want to bring your own PSTN carriage via an SBC to Microsoft Teams, then you have to do quite a bit of configuration within Office 365. This configuration is done using PowerShell and can be complex to understand for someone who hasn’t worked a lot with Skype for Business Enterprise Voice deployments in the past (or even if you have!). This is especially the case if there are multiple gateways deployed around the country or world and complex failover routing is required. In order to help to make this easier, I have created a new tool that gives you a full GUI for creating, troubleshooting and testing your Direct Routing configuration.

Teams Direct Routing Overview

Microsoft has done a pretty good job of documenting the configuration of Direct Routing for people that are familiar with the concepts of Voice Routing Policies, Voice Routes, PSTN Usages, and PSTN Gateways from the days of Skype for Business Enterprise Voice. The documentation is available at Microsoft Docs here: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-configure

The most helpful explanatory diagram from Microsoft’s documentation is the one below:

This diagram shows the components of Direct Routing and their relationship with each other. From a higher level it’s easiest to think of a Voice Routing Policy as being the container that has the routing elements inside of it. The Voice Routing Policy is assigned to a user and describes how calls from that user will be routed. Inside the Voice Routing Policy are PSTN Usages,which are containers that hold multiple Voice Routes. The ordering of both PSTN Usages and Voice Routes are important to the order in which calls will be sent to specific PSTN Gateways. The PSTN Gateway configuration contains all of the protocol related settings that describe information that will be sent to the physical SBCs you deploy.

The part that is most confusing about this is that Voice Routes have specific Priority settings that are assigned to them in PowerShell, which are used within a PSTN Usage to determine precedence and order of evaluation - however, this doesn’t tell the full story. The order of the PSTN Usage then functions as an overarching ordering for the Voice Routes. This relationship in diagrammatic form is relatively easy to see; however, when presented in PowerShell format it can be very difficult to understand. When designing this tool I decided to make it have the capability of helping the user easily understand the order in which routing will occur for any number dialled, by ordering everything in highest to lowest priority order.

The Microsoft Teams Direct Routing Tool

Tool Features:

• The “Connect to O365” button allows for regular and MFA based authentication with O365. Note: the Skype for Business Online PowerShell module needs to be installed on the PC that you are connecting from. You can get the module from here: https://www.microsoft.com/en-us/download/details.aspx?id=39366
• Select a User from the User drop down box to see their current Voice Policy assignment.
• Create and Remove Voice Routing Polices.
• Create, Remove, Edit and Order PSTN Usages.
• Add PSTN Usages to Voice Routing Polices.
• Create, Remove, Edit and Order Voice Routes.
• Add Voice Routes to PSTN Usages.
• Add Gateways and Regex Patterns to Voice Routes.
• Add, Remove and Edit PSTN Gateway settings.
• Enter a normalized number (ie. E164, +61400555111 style format) and click the Test Number button to see PSTN Gateways the routing order and failover choices for that specific number.
• What doesn’t it do? The tool currently doesn’t do Tenant Dial Plan configuration. This could be a future development item for a later version.

UPDATES

1.00 Initial Release

Download from TechNet Gallery:

DOWNLOAD HERE

Example of Tool Capabilities

As a basic example to show how the tool works, I will demonstrate making changes to the International Routing plan for Australia as created by www.ucdialplans.com (MVP Ken Lasko’s creation). The changes will be to add additional rules to allow calls to be sent via Direct Routing to On Premises PBX extensions (extension range 1000-1999). In order to do this, I will create a new Online PSTN Usage and added a Voice Routeto it, then change the priority of usages and finally test that the new rule works as expected.

Step 1:  Connect to O365 and select Voice Routing Policy

After importing the basic templates in from the ucdialplans.com site (which basically involved running a PowerShell script that I’m not going to document here in detail) I then opened the Direct Routing Tool from a PowerShell window. After the GUI loaded I then clicked the “Connect to O365”button and entered my O365 administrator credentials (Note: both regular auth and MFA based auth is supported). After doing this, the tool discovered all of the existing Voice Routing Policies and displayed them in the policies drop down box:

Note: In this example I am only making changes to the International policy for brevity’s sake. 

I then selected the International policy from the Policies drop down box. The tool then loaded all of the PSTN Usages and Voice Route data associated with this Voice Routing Policy in the main window:

Step 2: Create a New PSTN Usage

I then created a new PSTN Usage that will be used to allow calls to be sent directly to an On Premises PBX that has extensions in the number range 1000-1999. To do this I clicked on the “Add Usage…” button which then displayed the Add PSTN Usage dialog. In the dialog I selected the “New” check box to indicate that I’m creating a new policy and gave it a name that aligns with the convention used for the other PSTN Usages:

After clicking OK the PSTN Usage was added to the Voice Routing Policy. However, at this point it didn’t have any Voice Route associated with it so it wasn’t capable of routing calls. You will see in the main window screenshot below that the Voice Route, Number Pattern and Gateway List columns are empty:

Step 3: Add a Voice Route to the PSTN Usage

To add the Voice Route information to the PSTN Usage I double clicked the new PSTN Usage row (this can be done by either Double Clicking on the Usage or highlight the Usage and clicking the Edit Usage button). Once this was done the Edit PSTN Usage dialog was displayed:

Step 4: Add a Voice Route

From within the Edit Usage dialog a Voice Route can be added to the usage. This can be done by either Double Clicking the PSTN Usage row or Highlighting the Usage and clicking the “Edit Voice Route” or “Add Voice Route” Buttons. When creating a new Voice Route I recommend using the Double Click or "Edit Voice Route" button because this puts you directly into the "Edit Voice Route" dialog in a single step. Once the Edit Voice Route dialog is open I assigned it a Name, Number Pattern (in this case the pattern was “^1\d{3}$” to capture the 1000-1999 extension range) and PSTN Gateway.

After filling in the dialog I clicked OK and was returned to the Edit Usage dialog where I could see that the new Voice Route info was added to the PSTN Usage:

Having completed the configuration, I clicked the OK button on the Edit Usage dialog which took me back to the main window. You will now see that the Extensions PSTN Usage has the Voice Route information in the row at the end of the Usage list:

In this case I wanted the more specific Extensions PSTN Usageto be at the top of the list because it is more specific than the other PSTN Usages. I clicked the Usage Order button to open the Usage Order dialog which allowed me to move the priority of the Extensions PSTN Usage to the top of the list and then clicked OK:

The Extensions Usage was then moved to the top of the list in the main window:

This now completed all the configuration that I needed to get calls routing to the On-Premises SBC and PBX. However, it’s important to check that the Voice Routing policy is behaving the way you want it to before moving on. In order to do this, I entered an extension number with the PBX’s extension range in the Normalized Dialled Number box and clicked the Test Number button. The results are shown below:

Second Choice:

The tool now highlights all of the PSTN Usages and Voice Routes that will get used when this number is dialled. The information in the area below the "Choice Number" drop down box shows that the first choice for route calls to this number will be the new Voice Route that I just added, which is great. However, it appears that there is a second PSTN Usagethat will also be used as a second choice if the first choice is not available. In this case the second choice is matching against the “AU-SouthEast-Service” usage which was not intended as part of this configuration. This second choice route may result is calls being sent to sbc02 or even in the case of other Voice Routing Policies (that also have the “AU-SouthEast-Service” PSTN Usage) surreptitiously having the ability to dial the PBX extensions. The testing in this case has been very useful in uncovering an issue that may need to be corrected before running Direct Routing in production.

Gateway Configuration for Bonus Points: 

You may also need to create or make changes to PSTN Gateways within your O365 tenant. The good news is that the tool can also do this. Simply click on the “Gateways…” button to edit gateway settings or add and remove gateways from the tenant:

The Wrap Up

Thanks for reading the post and checking out this tool I created. You now have the power of Teams Direct Routing in your grasp: use this power wisely for good instead of evil. Best of luck with your Direct Routing configurations. Enjoy!

Read more →

Polycom VVX Not Displaying PIN Authentication Option

I had an interesting issue with a Polycom VVX deployment recently that I thought I would share in case others run into the same issue.

The Issue

The symptom of the problem was that after the Polycom VVX had completed booting, including getting an IP Address and downloading software/config files, the PIN Authentication option did not appear on the sign-in options screen. This meant that I was unable to use PIN Authentication at all for signing in the devices which was a problem because we planned on using it for all the phones. Below is an example of what the screen looked like:

Sign-in Screen without PIN Auth option

Troubleshooting

There was a series of steps that I went through in troubleshooting this issue. I will take you through all of them so you too can check whether your issue might be solved with some of the earlier steps that I tried before reaching a resolution.

STEP 1

I first confirmed that PIN Authentication was in fact turned on in the configuration file(s) of the phone. To do this I checked that the following setting was not in the configuration files:

<!-- Disable PIN Auth by setting "0" -->

<reg reg.1.auth.usePinCredentials="0" />

Note: The phone can have multiple configuration files that are both manually added by administrators and automatically created by the phone (ie. <MAC>-phone.cfg, <MAC>-web.cfg, etc). You need to check all of the files associated with the phone's MAC address to ensure it’s not being overridden by another file.

I also checked the setting directly in the phone using my VVX Phone Manager Tool to get the active setting out of the phone using the REST interface. In my case this setting was not configured in the config file and it defaults to being on (ie. set to "1"). So this wasn't the problem.

STEP 2

I checked that PIN Authentication was actually enabled on the Skype for Business server. This can be done in the Control Panel > Security > Web Services > Pin Authentication Enabled:

This was also enabled - so in this case it wasn't the problem.

STEP 3

I tested the PIN Authentication process on the server by running Test-CsPhoneBootstrap PowerShell command on the system. This worked just fine:

PS C:\ > Test-CsPhoneBootstrap -PhoneOrExtension 4500 -PIN 12345 -TargetFqdn 2015ENTFE004.myskypelab.com -TargetUri https://2015ENTFE004.myskypelab.com:443/CertProv/CertProvisioningService.svc

Target Fqdn   : 2015ENTFE004.myskypelab.com

Target Uri    : https://2015ENTFE004.myskypelab.com:443/CertProv/CertProvisioningService.svc

Result        : Success

Latency       : 00:00:01.2333041

Error Message :

Diagnosis     :

STEP 4

In this deployment there was a centralised Windows Server that was serving DHCP to all the client subnets. On the central DHCP server I confirmed that all of the DHCP options were correct using my Skype4B/Lync DHCP Config Tool. This tool parses the byte format Vendor Options and displays them as readable text, and if it is unable to parse the byte format it will display an error:

This is an example image from my lab

In this case, all settings were displayed and no encoding issues were detected by the tool, which means this wasn’t the issue. So I checked that there was no DHCP server on a closer subnet (ie. a switch or router) that was responding to DHCP before the central Window DHCP server. This also wasn’t the case as I could see that the central DHCP server had logged the address lease for the Polycom VVX with the particular MAC Address of the test device.

STEP 5

At this point this was starting to look like a more complex problem so I took to the lab to see if I could reproduce such behaviour.  I noticed that after a factory default the phone initially didn’t display the Pin Authentication option for a couple of seconds - it appeared belatedly. This indicated to me that there was some additional check that was being done by the VVX before it would display this option. So this begged the question: what is required for PIN Authentication to function on the VVX? The most important thing that is required is that the phone gets the DHCP Options which tell it where the Cert Provisioning services resides, so it can communicate with the web services required for PIN Authentication.

Given that the VVX phones were being issued IP Addresses via DHCP, it didn’t seem likely to be a connectivity issue between the VVX and the DHCP server. However, I looked into the traffic flows to confirm this and found something interesting. In this Wireshark capture, you can see that the DHCP Options get sent out in response to an INFORM message that the VVX sends. The INFORM message is a special DHCP message that is outside of the initial DHCP IP Address discover process (DISCOVER > OFFER > REQUEST > ACK). The interesting thing about the INFORM message is that the ACK for this message from the DHCP server gets sent as a Unicast response directly back VVX itself rather than to the DHCP Relay IP Address, unlike all the other messages. The screen shot below also shows this from the DHCP server perspective - you can see the final ACK message has a Destination IP Address of the VVX instead of the DHCP relay IP Address:

The highlighted INFORM ACK message in Wireshark shows that it contains all the additional Microsoft specific Vendor Class Options (Certificate Provisioning Service details). It’s the packet that has the information that the VVX needs to get PIN Authentication working.

In this case, because a centralised DHCP was being used, the broadcast DHCP messages on the local subnet were being changed into unicast messages by the local router and sent over to the central DHCP server. There was also a firewall in between this local router and the centralised DHCP server. This meant that because the returning INFORM ACK message was sent directly back to the phone (which is part of the DHCP specification and is correct operation) the firewall had not created a UDP flow for it and the packet gets blocked. The diagram below shows how the DHCP traffic flow works with a DHCP Relay in place and where the issue resides:

As you can see from the diagram above, the firewall appears to be allowing traffic from the DCHP relay through to the DHCP server. After transiting the DCHP relay, the DHCP traffic flows from source port 67 to destination port 67. Then the INFORM ACK message then gets sent back from source port 67 on the DHCP server to destination port 68 on the VVX -  which the firewall did not have an existing flow for and it dropped the packet. As a result, the VVX didn’t receive its required Cert provisioning service URL and because of this didn't display the PIN Authentication sign-in button.

The Solution

So the solution here, as it often is, is firewall related. In this case we had to allow port 68 from the DHCP server IP Address to all the VVX phone subnets. After this was done the INFORM ACK messages could flow as required for the VVX to get its Vendor Class options.

If you don’t have access to the firewall or you need a quick solution to the problem, you can hard code the data contained in the Vendor Class options into the phone. This was added as a config option in software version 5.3. The configuration item is shown below:

<dhcp dhcp.option43.override.stsUri="https://s4bwebint.domain.com:443/CertProv/CertProvisioningService.svc" />

This can also be set in the web interface of the phone in the Settings > Provisioning Server > DHCP Menu > DHCP Option 43 Override STS-URI:

The Wrap Up

For all the old-school UC people out there, let's finish with a Haiku in the style of the old Lync 2010 powershell blog:

Firewalls drop packets,

This causes many issues,

Switch off all firewalls.

Till next time, see ya! 

Read more →

Building an Edge Server Port Monitor with Azure Function Apps – Part 3

This blog is an expansion on the previous Part 1 and Part 2 posts found here and here. The process of setting up the Function App for this part 3 section is the same as was documented in Part 1 and 2.  I suggest you head over to the first two parts and give them a good read before moving onto this post.

In part 3 we will be adding to the Function App so it can save data over time that we can use to graph and manipulate in Power Bi. To do this we will expand the application to do the following:

• Save all port test results to Azure Storage tables for analysis.
• Use Power Bi to connect to Azure Storage Tables and create nice graphs showing the status of Edge servers over a period of time.

Just like in Part 2 we will use the Azure Storage Tables module for Powershell to allow our application to keep both a short term memory for logging errors as well as a long term memory for logging all port testing attempts.

Step 1

To begin with follow Steps 1 through 5 of Part 2.

Step 2 – Download a copy of the script

You can grab a copy of the script I wrote for part 3 from here:

Step 3 - Update variables

Update the Storage Account details in the Powershell Script.

IMPORTANT: These settings are slightly different than in Part 2. In this case we have 2 different storage tables: one of them stores the current state of edge servers (same as part 2) and the other one stores all attempts into a separate table (which we will use for analysis in Power Bi):

#AZURE STORAGE VARIABLES######

#SETTINGS ARE FOUND UNDER PLATFORM FEATURES TAB -> PROPERTIES

$subscriptionName = "Visual Studio Premium with MSDN"  #SUBSCRIPTION NAME

$resourceGroup = "EdgePortTester-Part003"      #RESOURCE GROUP

$storageAccount = "edgeporttesterp8dbf" #STORAGE ACCOUNT NAME

$tableName = "EdgeTesterTablePart3Current"      #CHOOSE A NAME 1

$tableName2 = "EdgeTesterTablePart3Results"      #CHOOSE A NAME 2

$partitionKey = "EdgeTesterStoragePart3Current"      #CHOOSE A NAME 1

$partitionKey2 = "EdgeTesterStoragePart3Results"      #CHOOSE A NAME 2

$storageAccountKey = "7asdkjhasd7KHDKJHAS0dsflasdnnlasd099asdpncsdlknclLJSDLjbadksdjbfa9su9duhoasivRqXA615jQ=="             #STORAGE ACCOUNT > ACCESS KEYS

#AZURE STORAGE VARIABLE END######

Don’t forget to fill in your Mail Jet email account information (as you did in Part 1) and add your Skype for Business Edge server's details. See Part 1 for more details. Enter your Mail Jet API Key (Username) and Secret Key (Password) and paste them into the following section of the script:

#MAIL JET USERNAME/PASSWORD#######

$emailUsername = "kjh3k23h4kjhkj37573f8f020879dff7"     

$emailPassword = "9898f98fhdjkkdjh46cd418100075a3b"

#EMAIL ADDRESS TO SEND ERRORS FROM

$SENDEREMAIL = "YourRealEmailAddress@domain.com"

#EMAIL ADDRESS TO SEND ERRORS TO

$RECIPIENTEMAIL = "YourRealEmailAddress@domain.com"

################################## 

Edit the Skype for Business Edge server details as required. These are entered as an array of hash tables. The sections highlighted in yellow can be changed. In this case the application is monitoring 2 Edge servers, one in Melbourne and one in Sydney.

Location	ServerName	ServerRole	DestinationPort	Protocol
Melbourne	147.70.50.10	Federation	5061	TCP
Melbourne	147.70.50.10	Access Edge	443	TCP
Melbourne	147.70.50.11	Web Conferencing	443	TCP
Melbourne	147.70.50.12	AV Edge	443	TCP
Sydney	147.70.60.20	Federation	5061	TCP
Sydney	147.70.60.20	Access Edge	443	TCP
Sydney	147.70.60.21	Web Conferencing	443	TCP
Sydney	147.70.60.22	AV Edge	443	TCP

Note: The script only supports testing TCP ports at this time.

#SETUP EACH SERVER

$Records = @(@{"Location" ="Melbourne"; "ServerName"= "147.70.50.10"; "ServerRole" = "Federation"; "DestinationPort" = "5061"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Melbourne"; "ServerName"= "147.70.50.10"; "ServerRole" = "Access Edge"; "DestinationPort" = "443"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Melbourne"; "ServerName"= "147.70.50.11"; "ServerRole" = "Web Conferencing"; "DestinationPort" = "443"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Melbourne"; "ServerName"= "147.70.50.12"; "ServerRole" = "AV Edge"; "DestinationPort" = "443"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Sydney"; "ServerName"= "147.70.60.20"; "ServerRole" = "Federation"; "DestinationPort" = "5061"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Sydney"; "ServerName"= "147.70.60.20"; "ServerRole" = "Access Edge"; "DestinationPort" = "443"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Sydney"; "ServerName"= "147.70.60.21"; "ServerRole" = "Web Conferencing"; "DestinationPort" = "443"; "Protocol" ="TCP"})

$Records += @(@{"Location" ="Sydney"; "ServerName"= "147.70.60.22"; "ServerRole" = "AV Edge"; "DestinationPort" = "443"; "Protocol" ="TCP"})

Step 4 – Parameter Tweaking

This version of the script like part 2 has a few settings that you can tweak. These are how many failures on each port is required before an email gets sent ($RequiredNumberOfFailuresBeforeEmail). There is also a setting for consolidating multiple errors or recoveries into a single email ($consolidateEmailsOnError and $consolidateEmailsOnError). Set these as you like:

#This is the number of required port check failures before an email is sent out

$RequiredNumberOfFailuresBeforeEmail = 3

#Send 1 email rather than one per record

$consolidateEmailsOnError = $true

$consolidateEmailsOnRecover = $true

Step 5 - Download Azure Storage Explorer

Now let your Function Application run for a while and gather some data. At any time you can look into your Function Apps Table Storage using Azure Storage Explorer. This application will show you all of the rows in your storage tables and allow you to see and edit as you see fit. You can download your free copy from here:

https://azure.microsoft.com/en-us/features/storage-explorer/

Once you have logged into your Azure Account within Azure Storage Explorer you can dig into your storage tables by selecting Storage Accounts > (Storage Resource Group Name) > Tables to see your table data. Note, there will be no table or data until you actually start running the Function App.

Step 6 - Download Power Bi

Now download a copy of Power BI for desktop:

https://powerbi.microsoft.com/en-us/desktop/

Install the downloaded Power Bi on your PC.

Step 7 - Open Power Bi

Open Power Bi Desktop and you will be greeted with a splash screen and dialog. Click on the “Get Data” button:

Step 8 - Import Data

The Get Data dialog will then be displayed. Select “Azure Table Storage” from the list and click the “Connect” button:

Step 8 - Account URL dialog

Power Bi will now request an Account Name or URL to connect to:

Step 9 - Find Account URL

The account name for the dialog above can be found in the Azure Portal under the storage account Overview > Tables section:

The “Table service endpoint” is the value you will need to fill in the dialog with:

Step 10 - Paste in URL

Enter the Table service endpoint into the “Azure Table Storage” dialog and click “OK”:

Step 11 - Enter Account Key

You will now be asked to enter your “Account Key”:

This can be found under the Storage Account > Access Keys section in the Azure Portal:

Enter the Account Key and click “Connect”:

Step 12 - Load Data

Power Bi will now connect to your Table Storage and list up all of the Tables in there. Select the Results table and click “Load”:

Step 13 - Not all data is displayed

Power Bi will now download your data into the application. You may notice though that all of the columns that you can see in Azure Storage Explorer will not be displayed:

Step 14 - Edit Query

To be able to see all of the columns you need to do a little extra work. On the right hand side of the screen, Right Click on Table name at the top of the top of the column names listed and select “Edit Query”:

Step 15 - Expand content column

You will now see an extended view of the data that includes a “Content” Column:

On the top right of the Column click on the double arrow “expand” button:

You will now get a full list of all of the additional columns available that are stored in Table Storage as a Json blob. Tick the Columns that you want to include in your graphs and data analysis and click OK:

Step 16 - All columns are now available

You will now see the extra data columns:

 Click the “Close and Apply” button from the Home Tab:

The full array of data is now available for you to do as you please with:

Step 18 - Make charts

Back on the "Report" tab you can now put together some nice looking graphs of your data. Here is an example of a Pie Chart and a Bar Chart showing information about the number of errors for each role:

To create these graphs you use the following settings:

From here you can play with the data in Power Bi and make whatever graph you like (I included location in the data so you can even plot your Edge servers on a map). This is what makes Power Bi so powerful!

The Wrap Up

This post ends my series on creating an Edge port monitor with Azure Function Apps. I hope that in addition to helping you monitor your edge servers, this has been informative and taught you some new skills that might help in the future when making your own Function Apps.

Read more →