Operating system not correctly shown for Windows servers

[SaschaSeipp]

The documentation states:

Operating system - The operating system running on the device used [to] sign-on to your tenant.

which is also what one would expect. But if a user logs on to to Azure from a Windows Server (be it a Terminal Server or an admin doing some backend work on a regular server), these logons are instead shown as "Windows 7" for Windows Server 2008 and "Windows 8" for Windows Server 2012.
This is a problem for us, as we want to identify users still working on real Windows 7 and Windows 8 machines. Why is Azure not showing the proper data here?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1558e7c0-eaaf-d081-30c3-5c13e0876071
• Version Independent ID: 1106c01b-1e4c-5b04-be84-432f99ec4d8f
• Content: Sign-ins logs in Azure Active Directory
• Content Source: articles/active-directory/reports-monitoring/concept-sign-ins.md
• Service: active-directory
• Sub-service: report-monitor
• GitHub Login: @MARKUSVI
• Microsoft Alias: markvi

[JamesTran-MSFT]

@SaschaSeipp
Thanks for your feedback! We will investigate and update as appropriate.

[JamesTran-MSFT]

@SaschaSeipp
Thank you for your detailed post!

• Would you be able to share a screenshot of what you're seeing?
• When you mentioned - If a user logs on to to Azure from a Windows Server, are you referring to a Web browser, CLI, or PS? All login methods aren't reflecting the incorrect OS?

Any additional information would be greatly appreciated.

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.

[SaschaSeipp]

@JamesTran-MSFT
Thanks for looking into this. As for my test conducted yesterday, I was logging in from a (rather old, I know) Windows Server 2008 R2 Enterprise with a gruesomely old Internet Explorer 8 (in my defence, that server is on the "to-be-deleted list" and usually doesn't connect to the Internet 🙄). While the browser was detected correctly, the operating system was not:

On the other hand, I did download the Azure AD SignIn logs for our tenant from the last month or so and filtered them for instances of "Windows 7" and "Windows 8", where we still had a significant number of entries (with clientAppUsed mentioned as "Browser" with various browsers, but also as "Mobile Apps and Desktop clients"). But when I asked my client management colleagues about it, they were confused, because most of those users only have Windows 10 PCs. But apparently some of them still use some older Terminal servers or do login from other servers for various reasons.

While we obviously also have to get rid of the old servers at some time, it doesn't help to see incorrect data to set an action plan.

Now that I come to think about it, there is even more to it, not just servers being shown wrong:
For some "Windows 8" entries, the machine is shown as "Azure AD registered", which adds the hostname to the log entry. But if I check that device for its Azure AD registration, it is only shown as Windows 10 in there. And in the log, there are lots of sign-ins for those users, but only a couple of entries shows "Windows 8" (in "impossible" variations - users usually do not change their operating system back and forth in a couple of minutes).
Those might be temporary wrong entries for some reason - but this is still problematic when just filtering for those entries in trying to find the real culprits.

Examples:

1. User is logging in several times in between around 3 hours, and the same device ID is logged showing W10, W8, W10:

2. User is logging in a couple of times, but in around one minute, his OS changes from W8 to W10. And while the registered Azure device is actually registered as a W10 device, it is only shown as registered when falsely stating W8, but not at all when showing W10:

3. Same as before (with yet another user), but now it's not just 'Browser', but also 'Mobile Apps and Desktop clients' involved:

All in all, I find these findings rather disturbing - up until know, I thought I could rely on this data. I suppose if we were to for instance put up a Conditional Access policy blocking access for Windows 7 and Windows 8 clients, we would be in real trouble with this false data.

[JamesTran-MSFT]

@SaschaSeipp
Thank you so much for the quick and detailed response!

Based off the information you provided, we'd like to take a closer look into your environment and issue, can you please email me with the info below. I'll go ahead and enable a one-time free technical support request for your subscription so you can work with our support engineers to get this issue resolved.

-Removed email instructions-

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.

[SaschaSeipp]

@JamesTran-MSFT
email is on its way. 😃

[JamesTran-MSFT]

@SaschaSeipp
Thank you for the email! I'll go ahead and close out this thread.