Office 365 Service Health Guide

The Office 365 Service Health scripts were designed to help you keep informed about the status of your Office 365 Tenant.

Just in case you missed the memo, there's a lot of changes happening on the platform every second of every day. Some intentional, some not!

And to view these changes, you have to sign into your tenant, check the messages, check the advisories, check your licences, move to the documents site ("TechNet" for the oldies) and check the IPs and URLs haven't changed. Then maybe you need to download the usage reports.

Wouldn't it be nice to have this all in one place? Wouldn't it be really nice not to have to give all the staff an admin role just to see any outages/issues? I thought so :)

I've put together a few scripts to help do that. The scripts pull your tenant information from a configuration file (XML) and output a few HTML pages, some log files and some CSV reports if needed.

So lets start at the beginning

Prerequisites

Lets get all the pieces together first

• An Azure App with Service Health (Office 365 management API), Reports.Read.All (Graph API) and Organization.Read.All (Graph API)
• A web service to host the html output
• A task scheduler to run the command lines on a regular basis.
• The PowerShell files: https://github.com/JonathanChristie-BHIT/Office365-Info

Azure AD App
Lee Ford (others great bloggers also available!) has a great step-by-step article on how to create an app, so there's no point in reinventing the wheel!: https://www.lee-ford.co.uk/get-latest-office-365-service-status-with-flow-or-powershell/
Its also worth looking at consuming the App in Flow and pushing to teams - having an 'in-cloud' monitoring solution can help pinpoint local issue (ie proxy, internet access). Similarly having an on-premises solution allows you to test from a user perspective and also works during teams/flow outages :) 

Download the file from GitHub, and extract
https://github.com/JonathanChristie-BHIT/Office365-Info 

Rename and complete the config.xml file
The config file has grown as I've centralised the common data and variables between the scripts. It should be straight forward with the examples given. I've tried to highlight the required fields but these should be fairly obvious (i.e. you'll need the email section if you want the system to generate and send emails)
I've also created a UpdateProfile.ps1 script which will update older config.xml files with new variables as/when they are introduced.

First Run 
On first run of any of the scripts, if you're going to use the local event log, then 'run as admin' in order to create the event log and source information.

ConfigXML 
All scripts take the parameter -configXML which expects the path to a completed config file. The config.xml file is always relative to the ps1 script, not the location that its being called from.
ie if calling from the folder above the scripts it would be:
.\dashboard\O365SH.ps1 -configXML ..\config\profile-prod.xml -RebuildDocs
dashboard is the script location. It traverses up one folder (..) and into the config directory for the configuration (\config)

Each config file can be for a different tenant, different output locations etc

Dashboard
The first script to run will probably be the Dashboard script. This gives you a quick summary of the stat of your tenant with outages and messages. For a first run use the -RebuildDocs parameter to generate a local html file of all messages and incidents (otherwise some of the hyperlinks may fail)

So to generate the dashboard output, call the dashboard script with the config and -RebuildDocs parameter:

 .\dashboard\O365SH.ps1 -configXML ..\config\profile-prod.xml -RebuildDocs

If your config is good, you should be presented with an html output file in the your designed location (specified in config file). Check the log directory for any issues .\logs\O365Dashboard-xxxx.datetime.log

Wall

Once the dashboard is up and running, the next script would be 'The Wall'. This is essentially the 'Features' tab on the dashboard output, but without the frills and distractions. A suitable candidate for large monitors, dashboard screens etc

It can also be browsed to from the dashboard file, logs tab, 'Information Wall'

As with the dashboard, simply pass the config file and the file will be generated.

.\O365SH-Wall.ps1 -configXML ..\config\profile-prod.xml

These can be called as a scheduled task and run at intervals

ie a batch file could contain:

cd C:\Scripts\O365SH\Dashboard\

powershell.exe -file .\O365SH-Dashboard.ps1 -configXML ..\config\profile-prod.xml

cd ..

cd C:\Scripts\O365SH\Wall\

powershell.exe -file .\O365SH-Wall.ps1 -configXML ..\config\profile-prod.xml

cd ..

etc

Diagnostics/Toolbox

Diagnostics script pulls together some more technical aspects of an office 365 tenant

• The IPs and URLs that Microsoft publish for Office 365 and tests them for connectivity
• It will show your licence SKUs and sub-items
• The current IPs and URLs as well as the history of changes
• List of the URLs broken down into Optimize, Allow and Default categories
• The ever changing CNAMEs of office 365

CNAMEs can be hidden if they are of no interest (ie you have no DNS lookup restrictions)

.\O365SH-Toolbox.ps1 -configXML ..\config\profile-prod.xml

Monitor

Monitor is the real workhorse of the sutie. It should be run on a more regular basis than the others (maybe 5-10 mins). It tests the CNAME lookups, checks for new messages and issues and email (if configured)

.\O365SH-Monitor.ps1 -configXML ..\config\profile-prod.xml

Usage Reports

This script downloads the office 365 usage reports. The reports to download are passed as a parameter (to a .json list of reports). Report interval (180 day, 30 day etc) can be passed at the CLI too. This should give maximum flexibility.

I'm going to put together a series of articles on each of the above steps which should help (i'm very much a 'learn by doing' kind of guy. With pictures!)

Email Credentials 

If building the keys and password file, load the common module O365ServiceHealth.psm1 and call 'savecredentials'. Using the createkey parameter will create a new 256 bit (32 bytyes) key file. 
It is advisable to lock the folder down using NTFS permissions to limited accounts which will need access.

ie:
import-module .\O365ServiceHealth.psm1
saveCredentials -Password mypassword123456 -createkey $true -Keypath c:\creds\password.key -credspath -c:\creds\password.pwd

If you use Office 365 to send the notification emails, you must send from an account that has a mailbox.

Personally I have the dashboard running every 15-30 mins for users. The 'wall' and monitor (for emails) every 5-10 mins for tech staff.