Forum Discussion
Device Management in Teams, URLs and IP address ranges
You should only have to open for the URLs and addresses mentioned in the Office 365 URLs and IP documentation. https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges#skype-for-business-online-and-microsoft-teams
Other addresses it tries to connect to is since it is running Android and Android will try to connect to those addresses. NTP settings you can change in the phone settings so you use something else than ntp.org if you want to.
Updates should be downloaded from Microsoft servers after you have approved them in Teams Admin Center or when you trigger a phone to update firmware or software from TAC.
You should only have to open for the URLs and addresses mentioned in the Office 365 URLs and IP documentation. https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges#skype-for-business-online-and-microsoft-teams
Other addresses it tries to connect to is since it is running Android and Android will try to connect to those addresses. NTP settings you can change in the phone settings so you use something else than ntp.org if you want to.
Updates should be downloaded from Microsoft servers after you have approved them in Teams Admin Center or when you trigger a phone to update firmware or software from TAC.
thanks for the reply
however the url
https://teamsdevicemgmtsvcprod.blob.core.windows.net
appears to be where the phone firmware is actually downloaded from
i noted this in my network capture (looking at dns queries) and the article I linked to also noted this in the phone logs Plus actually pulled firmware from the url.
i can’t find mention of this in any ms documentation. However you are welcome for you to prove me a liar!
so you can see why I am a bit worried. If this is true, what else might there be.
AlistairKeay1 sorry to dig up such an old topic, but did you find a definitive answer on this? I've had a phone working intermittently (keeps getting stuck at the Company Portal app) on a network with just the currently published web service IPs and have noticed denies for addresses which point at things like mobile.azure.com and/or in.appcenter.ms. I don't know if they're critical, but it would be nice to figure this out.
