How and why I created the Office 365 Data Retriever Tool
Today’s post is a bit different. I’m not going to share how to do this in SharePoint, or that in Office 365. Instead, I’m going to share how & why I created the O365 Data Retriever tool, which I made available on Github yesterday, Aug 22nd 2018.
Why did I create the tool?
A few months back, I was looking at doing something on my spare time, that would improve my skills in PowerShell, or maybe SharePoint. Then, one of my colleague mentioned that he had to build a tool for the support team, to make it easier for them to manage users in Active Directory. And I was like “but how are you going to do that? 🤨”. Then he showed me a few videos. And that was so interesting, that I came back home, and watched most of them straight away.
Now, I needed to find an idea for the tool. What is it going to do?? Think about all the cmdlets you have to run, separately, in Office 365 to get back all the information you need, from different workloads (SharePoint, Exchange, users…). Well that could be an idea! And a good learning experience too.
After browsing the net, there was a clear indication that not every admin is using PowerShell to manage Office 365, or even other products. This leads to an important thought, that’s widely known in the community: Do not assume that other people have the knowledge that you have. It’s not because you know how to run Get-MsolUser that everyone knows it too.
So if I create that tool, maybe some people will really be interested, it’ll be helpful for some, and by sharing on Github, I can try to get people to contribute and make it better. Thinking of my first love (SharePoint), collaboration was important for me. So it made total sense to do it this way.
The last attempt I made to have confirmation people would be keen for it, is by asking on Twitter and the response was overwhelming, with a lot of enthusiasm 😊. So I went for it!
How did I create the tool?
So I started old school… Pen and paper. Lay out the ideas, the technologies the tool could be used for, and also started a mock-up for what it would look like, etc… And here we start. For real. Open Visual Studio, create a new WPF App, and be faced with a blank canvas 😧. OK…. What now?
Well, look at your mock-up, and try to make it look like on the paper. Then bind your buttons, textblocks, and grids in the PowerShell script. Run the script, click the button and… Damn! It works! That moment when all your services are displayed in a box after clicking on the Get Services button. Amazing and original, I know.
Fast forward a few weeks later, the tool doesn’t look like your mock-up anymore, many things are added and spun around, tabs for multiple Office 365 workloads started popping out, and before you know it, your PowerShell script is 1000+ lines of code… That’s when you realise comments are really important, as well as regions. But that’s my opinion. And I really needed to do that in order to know what’s what, and where!
I tried to make my script in order of the tabs. If the SharePoint Online tab is further down the line on the graphical part, then it is too in the PowerShell script.
I also wanted some sort of a modern design, and a bit of visual enhancement. I found a great blog post by Trevor Jones for customizable WPF MessageBoxes. And that’s what I used in my tool when entering the wrong credentials, or when you click on the disconnect button. It’s very well explained, and easy to put in place.
In conclusion, I hope to maintain the tool as much as possible and count on the community to participate so we can make it better. As for the learning curve, I really learnt a lot in the process, and totally happy I started it! Maybe more to come 😉