Office 365 Service Health Overview
The Office 365 Service Health scripts have grown from a simple script to a collections of scripts with central configuration files. This can make it look quite complicated but its straight forward.
pre-reqs:
Lee Ford (others great bloggers also available!) has a great step-by-step article on how to create an app, so theres 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 also created a profilebuilder 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 an 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
RebuildDocs
When running the Service health dashboard (O365SH.ps1) you can use -RebuildDocs parameter to build all the local html files for advisories and incidents.
ie .\dashboard\O365SH.ps1 -configXML ..\config\profile-prod.xml -RebuildDocs
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.
pre-reqs:
- 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.
Lee Ford (others great bloggers also available!) has a great step-by-step article on how to create an app, so theres 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 also created a profilebuilder 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 an 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
RebuildDocs
When running the Service health dashboard (O365SH.ps1) you can use -RebuildDocs parameter to build all the local html files for advisories and incidents.
ie .\dashboard\O365SH.ps1 -configXML ..\config\profile-prod.xml -RebuildDocs
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.
Comments
Post a Comment