BITS Downloading App updates from unknown endpoint
Hi, Our IDS started freaking out today because a large number of our endpoints started initiating BITS downloads to an unknown endpoint. My initial reaction was ransomware, but after further investigation it appears that these BITS downloads are updates for Windows Store Apps. I am making this post to confirm that these endpoints are actually indeed official Microsoft endpoints. The BITS requests I had seen were all for the Limelight Networks CDN (llnwd[.]net), which I have heard hosts content for a lot of MSPs, one of which being Microsoft. Checking the logs, it appears that our workstations have never made BITS requests to this CDN. All previous BITS updates were carried out using official microsoft.com endpoints. The following are some examples of the domains seen in the BITS requests: ic-c39e4900-0f7065-msftstoretlu19.s.loris.llnwd[.]net ic-c39e4900-0d5ab5-msftstore19.s.loris.llnwd[.]net ic-c39e4900-08b3f9-msftstore19.s.loris.llnwd[.]net ic-c39e4900-0700f8-msftstore19.s.loris.llnwd[.]net Although all my investigations point to these being official Microsoft endpoints, I am worried that a CDN is being used because a malicious actor could easily mangle the URLs to make them look like official Microsoft ones. Is this the correct place to confirm that the above sub-domains are official Microsoft, and if not where should I ask this question instead? Thanks
Transferring Business Premium Licenses Between Partners
My understanding is that NCE imposes a strict limit of 300 Business SKU's per tenancy. If we are transferring from a different CSP partner to ours we normally purchase the licenses first and then ask the other partner to cancel. If we wish to transfer 290 Business Premium licenses then I presume that this process won't work?
No MoH from SBC when transferring
Found an interesting scenario that breaks your SBC MoH for call transfers. If you are using the Teams desktop client to answer calls, and you happen to put a call on hold and then resume it, you will then no longer receive re-invites from Teams when you press the Transfer or Consult then Transfer buttons for the rest of the call. This means your SBC has no idea that it is meant to start the local playback of its local MoH file for transfers. This will only happen if you put a call on hold and resume it before attempting transfers. If you attempt a transfer without using hold beforehand then there is no issue. It seems that Teams no longer sends re-invites for calls that are placed on hold and resumed in the desktop client, but then it forgets that it's meant to do it if you want to transfer the calls afterwards. Not and issue on the Poly CCX 400 desk phones that I tested with as they still send re-invites for call hold and resume. Has anyone else come across this and is there anyway to change the Teams behavior of no re-invites for Hold and Resume with the desktop clients? I have tested this on 2 separate Teams tenants with SBCs from different vendors for validation.
