(Originally posted on LinkedIn February 21, 2022)

Every now and then I like to do a little investigative work – to “take a peek under the hood” of Microsoft 365, if you will.

A few customers recently brought up the question of the storage location of the registered attendee reports generated by Teams Webinars. These reports let Teams Webinar organizers get an early overview into the people registered to attend their event and are a pretty good tool to help tailor the contents of the webinar to the interests of those present, among other things.

The report is available in the Teams Webinar edit window for the organizer and is delivered as a .CSV file containing first names, last names and email addresses of each registered attendee – along with any other answers to custom questions they might have provided. You also get the total page views for the registration form that, when compared to the amount of registrations, can help understand the degree of interest in the event in the forums the registration link was posted on.

The storage location of the report is of interest especially because of person register laws in some countries – namely, the creation of new person registries in the form of .CSV files can be an issue if such files are stored, say, outside of the EU.

I didn’t find 100% clear information to clarify how the registration report is stored so I investigated.

DevTools to the rescue

Chromium-based browsers’ built-in DevTools are a great asset when figuring out cases such as this one. You can also access them in the Teams Desktop client.

I created a new Teams Webinar and registered into it with a single account to generate the option to download an attendee report. Then, I fired up Teams for the Web and used the Network tab in my browser’s DevTools to isolate and capture the traffic happening when I downloaded the report as the webinar organizer. Here’s what I saw:

When a Teams Webinar organizer presses the button to download the report, the Teams client sends queries to the following two endpoints in Microsoft’s internal Teams API through an IP that geolocates to Redmond, WA, USA (that is, Microsoft’s headquarters and campus):

• https://teams.microsoft.com/api/webinar/prod/webinar/<unique webinar identifier>/report/premeeting – this resource provides registered attendee details
• https://teams.microsoft.com/api/webinar/prod/webinar/<unique webinar identifier>/report/bi – this resource provides the registration page view count

The API used was the same regardless of whether the tenant is using Teams Multi-Geo or not. The home locale of the tenant and the language of the client were passed as cookies in the API request (TSREGIONCOOKIE & clocale, respectively), among other data points.

The response from both queries is returned to the client in JSON format – here’s an example of what the /premeeting response contains:

The client then seems to wrap the information of both queries up into a nice .CSV format and offer it to the user in real-time. A new .CSV is similarly generated from fresh queries every time the download button for the report is pushed.

This is quite the desirable outcome since implementing it like this makes sure no new permanent person register is pre-created and stored as a file in any potentially problematic location, avoiding legal and regulatory issues.

That’s it for this quick one!

-Tatu

UPDATE Jan 2023: Microsoft’s Alex Shteynberg graciously provided the following additional information on what is going on with webinar registration data etc. on the service end:

“Currently from service POV, this data is landing in OneDrive for Business (ODB) of the webinar creator. Which means that multi-geo is supported. For structured data (registration, speakers, etc.) there are multiple lists which you can see by going to [ODB]/_layouts/15/viewlsts.aspx?view=14. Unstructured components (agenda, notes, etc.) of the webinar are Fluid-based services and stored in [ODB]/Meetings.“