Event banner
Event details
I would like to ask Microsoft the following question: If #Microsoft was so serious about "Zero-Trust" security, then, it could have made all forms of their log dumps - read-only - so that, #B2B clients, & Microsoft support agents alike, would be assured that the data uploaded by the former to the latter's #FTP site has genuine integrity ! So, why hasn't it done so ?!? This has already been done for the online, & on-premises #B2C consumers alike, with the Microsoft Support Diagnostic Tool, (#MSDT); whereby an "#ActiveX control...is used to securely transfer files, & diagnostic utilities from Microsoft, & to upload information back to Microsoft. This file is stored in the %windir%\Downloaded Program Files folder." (Source: https://tinyurl.com/54arvefa) Verbosity-levels too, are set before logs are collected. So, with this tool, operator error isn't possible either inadvertently, or intentionally, as the process is automated, & the logs are read-only. However, with the case of #B2B customers' logs, only those who are cloud-based customers, have such protection. "If you sign in to the Microsoft Support & Recovery Assistant, (#SaRA), by using an account in #Office365, you also see an option to send your files to Microsoft. This option is helpful if you are working with a Microsoft support engineer. Select Send to have your log files securely uploaded." (Source: https://tinyurl.com/hb3by3v3) However, on-premises B2B customers are not so well-protected, & the integrity of their data can be doubtful, when it is in the hands of IT admins or agents alike ! This has proved costly, recently, when an IT Admin intentionally damaged his firm's #M365 cloud network. (Source: https://tinyurl.com/ad3vffrt) So, IT Admins aren't above reproach ! The only possible reason I could think of why Microsoft has left this gaping loophole open is that, some diagnostic packages may require enabling tracing, or specific logs that may "remain" enabled on the computer until the diagnostic uploads troubleshooting information to Microsoft Support. A support agent cannot simply have the IT admin client upload these logs while on call with them, as these logs have to "remain" enabled for sometime, longer than the duration of the average phone call between any parties, for these logs to be useful enough to Microsoft utilities to identify & analyze the root cause. In hindsight, an urgent work-around is necessary to restore confidence in the Integrity of Microsoft support !