In a recent announcement in Message Center, Microsoft is letting customers know about upcoming changes to how Office 365 IP address and URL details are published. These details are used by customers who require specific firewall or proxy rules to allow their users and devices to access Office 365 applications and related services.
The changes are:
- A new REST web service has been created to access the data in JSON and CSV formats
- The existing support document, XML file, and RSS feed are planned for removal in October 2018
Previously, and until October 2018, Microsoft has maintained a support document listing the URLs, IP address ranges, and ports that are required or optional for Office 365 connectivity. Customers who do not limit outbound client connectivity have little need for this information. It is primarily used by those organizations who restrict outbound connectivity, and who want to configure the appropriate firewall and proxy rules to permit Office 365 applications to work.
Aside from the useful and human-readable support document, the data has also been available as an XML file and sample proxy PAC files. An RSS feed has also been used to publish changes. All of those sources are planned to be retired.
The replacement that Microsoft has developed is a REST web service. The web service can be polled for:
- A list of endpoint instances and their last update time (there are separate instances for Office 365 worldwide, China, Germany, US Gov DoD, and US Gov GCC).
- A full list of the current configuration recommendations for each instance.
- A list of the latest changes for each instance.
The REST web service returns data in either CSV or JSON format. The CSV file is the most human readable, but is not as friendly as the current support document.
The JSON data is, naturally, quite unreadable. But that isn’t the purpose of the JSON feed. It’s intended for consumption by automation processes, or by firewall and network management tools that can ingest the data and automatically configure the appropriate rules. Many vendors have this capability for the existing XML file, and can automated updates using the RSS feed as well. So it’s expected that those vendors will simply adjust to the new JSON format.
You can of course write your own PowerShell scripts, or use another coding language, to make use of the JSON data. PowerShell cmdlets such as Invoke-WebRequest, Invoke-RestMethod, and ConvertFrom-Json are useful for that purpose.
Microsoft provides a sample script in PowerShell and Python on this page (scroll down near the bottom) which you can use as a starter. The sample script polls for changes since the last time you ran the script, saving results in a temp file to detect when changes have occurred.
Overall, this change makes sense from the perspective of automation. The REST web service should provide a better and more flexible experience for vendors and anybody who writes their own custom scripts to consume the data.
Unfortunately, we lose two good things in the process. The support document is the only human-readable source of this data that Microsoft provides. It’s the type of document that people can sit together and discuss as they go through it. Hopefully some PowerShell enthusiasts will develop a script to generate a user friendly document from the data, and share that with the community.
The other loss is the RSS feed. Whether the feed was used for automation, or merely as a notification, it is handy to have something provided by Microsoft to let us know when changes have occurred. RSS is also simple to consume in a feed reader, convert to an email notification, or send to a channel in Teams. Without the RSS feed, we need to create our own script or tool to poll the REST web service, detect changes, and send our preferred notification. Again, hopefully some PowerShell enthusiasts will solve this problem for the community.
You have until October 2018 to plan for this change. Keep an eye out for announcements when the REST web service becomes generally available. It’s currently in preview, and “shouldn’t be relied on in production”, according to Microsoft.
If you have feedback for Microsoft on this change, there’s a discussion thread here in the Microsoft Tech Community.
[adrotate banner=”50″]
Changes of this kind can significantly affect the interaction. Before using a proxy service, you need to study the privacy policy and agreement on use – it will describe in detail what data is collected and stored and for what purposes, what actions are prohibited. I advise about one of the best read more here https://proxybros.com/reviews/netnut-io/
Does MS provide a running list of updates? It’s a pain to have to review the entire list for changes each time they update the list.
thanks
Hi Daisy, Ishan Ahuja and Eugene Beran,
did anyone find out what is the minimum FQDN’s and the IP Addresses need for Azure and Exchange online?
I would like to know that as well
Thanks, Paul. I cannot use the REST directly with my firewall.
https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
My firewall allows me to put in FQDN’s with and without wildcards. Do you know – do I need to do the FQDN’s and the IP Addresses or are the FQDN’s listed good enough? Thanks!
Hello Eugene,
I have the same question. Did you got the answer for that ?
Pingback: Powershell and Automation Newsletter May 2018 – Powershell for the Modern Idiot