In the summer of 2018 I worked at Microsoft as a Program Manager Intern as part of Enterprise + Cloud Engineering, a team under M365 Core. M365 core is a group that works under Microsoft Experience + Devices. The team that I was a part of worked on a feature called Customer Key.
About Customer Key:
With Customer Key, you can control your organizations encryption keys and then configure Office 365 to use them to encrypt your data at rest in Microsoft's data centers. The data at rest includes data from Exchange Online and Skype for Business that is stored in mailboxes as well as files that are stored in SharePoint Online and OneDrive for Business. This feature was created due to the growing number of regulations around the world that require that companies own their own encryption keys for their data at rest. Microsoft's Customer Key feature addresses these new regulations and unblocks customers to allow them to us the O365 service. Customer Key became generally available in September of 2017. It is an add on to O365 E5 or Advanced Compliance.
What I Did:
I created Customer Facing Reporting for Customer Key to sit within the M365 admin center. What this did was allow customers to see how fast their mailboxes were being encrypted, how many they had encrypted, which ones were on the data deletion path, etc. The only problem with the previous method was that the only way to access this data was to run PowerShell cmdlets.
Problems with PowerShell:
The biggest problem that with PowerShell is that it is a very ineffective way to look at data. When you run a cmdlet, it only tells you which mailboxes have been encrypted in a list form. There was no analysis of data or any form of reporting. All analysis has to be gleaned from the raw data by the customer. To add on to that issue, many customers were also unfamiliar with PowerShell. Usually when a product is released that is controlled through PowerShell, IT departments are the ones that use the product. In this case, we were getting clients who's legal departments were the main users.
With PowerShell there was no way to see the state of encryption or any of the reports customers wanted.
Outline of Process:
I started by setting up the feature in a test tenant in which i ran through test scenarios and went down the data deletion path for a Data Encryption Policy. Through this I was able to understand some of the key pain points that customers were having as well as I was better able to understand what data a customer would need to know. I also learned how to operate the Customer Key feature. I also read through client emails, sat in meetings, and talked with coworkers to brainstorm all the possible issues and key values that customers would need to see in reporting.
From the data I had collected and requirements that I had been established from my research and from my manager, I created a project spec and mocked up a basic layout that illustrated the basic framework and layout.I created a simple prototype demonstrating the flow and feel.
From the data that I had gathered, I also determined how to showcase the data and best represent certain figures. I began working in PowerBI to make an actual prototype of the Customer Facing Reporting. My prototype would pull from existing data sheets from Cosmos (Database) analyze the data for each individual graph or report. As the data was in a raw format, I had to problem solve and create an analysis for each report that would pull the necessary data for each report and present it in an easily readable format.
Future goals for this project for its implementation would be to have the reporting sit on top of the PowerShell scripts and pull from Azure DataLake instead of Cosmos. I also planned to have greater flexibility with graphs and to expand this reporting feature beyond the tenant level.
Customer Facing Reports:
I was one of two people chosen to present at Microsoft's OneWeek Expo to Rajesh Jha, Microsoft EVP and Head of E+D. After my presentation, he remarked "your work is extremely important".