PowerShell – How to find users without default quota set on Microsoft Exchange

I’m working on a new feature for one of my modules that requires me to know what kind of files I am working with. It’s quite easy in PowerShell, and without a lot of code, you can reasonably quickly get necessary information about data stored on your desktop or anywhere else for that matter.

As part of my daily development, I create lots of code that I subsequently comment on and leave to ensure I understand what I tried, what worked, and what didn’t. This is my usual method of solving a problem. Sure, I could commit it to git and then look it up, and I do that, but that doesn’t change my behavior where I happen to have lots of “junk” inside of my functions that stay commented out. While this works for me, and I’ve accepted this as part of my process, I don’t believe this should be part of the production code on PowerShellGallery or when the code is deployed.

Recently I got a simple task to implement LAPS for the newly created local user instead of using the built-in local administrator account. It seemed easy at first. Go to Group Policies, create a new user, add it to an administrators group, and then follow standard steps to implement LAPS. That is until you find out it’s actually not possible anymore due to password encryption key being available in the wild, which made Microsoft block that Group Policy Preference. While that road is blocked, I still need to get my user-created somehow. Let’s do it with PowerShell. It’s quite simple – use New-LocalUser a few parameters, some random password that I don’t need to save as LAPS will overwrite it. Except it’s not available on PowerShell 2.0, which is the default for Windows 7 that I have to support. Things get even more complicated if you consider that Administrators group is called differently in different countries. While I stopped supporting anything below PowerShell 5.1, I can’t say if it’s the project requirement.

One of the most comfortable output’s in PowerShell to work and analyze data is Out-GridView. It’s handy as you can search, sort and have things done quicker than trying to do things in the console. However it’s currently not available in PowerShell Core (PowerShell 6+), and when it is available in PowerShell 7, it will NOT be cross-platform.  Since I had released Dashimo a few days ago, I thought it was trivial to make a simple command out of it that could solve this problem.

I’ve been in IT for a longer time now. I’ve made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.

Today I saw an article from Christian Ritter, “PowerShell: Creating an “empty” PSCustomObject” on X that got me curious. Do people create empty objects like Christian proposes? I want to offer an alternative to Christian’s article, which uses OrderedDictionary and converts to PSCustomObject.

I’ve been managing mail service for users for a lot of years now. I don’t do it daily but I’ve spent my fair share of time analyzing spam emails. Mail vendors are doing what they can fighting spam, but it’s not easy. Each month, each year spam is getting more sophisticated. Spam emails either look like a legit email, or worse someone is targeting your company trying to get them to transfer money into a wrong account. While most of those end up in spam, there are those that come thru. It’s even worse if the company you work with has not implemented SPF or their SPF is configured to soft fail which can’t be treated as spam.

Last few weeks, I’ve been working on making creating HTML based Dashboards, Reports, and Emails better. PSWriteHTML already allows fancy looking reports or emails without much effort, but this release makes it even more helpful. I will be mixing three PowerShell modules in this blost post – PSWriteHTML (responsible for creating HTML/CSS/JS code), Emailimo (simplifies creating emails based on PSWriteHTML) and Dashimo (simple dashboard building). If you’ve never heard of those modules before I encourage you to start from earlier blogs about them to understand the concepts before you dive into this one.  Hopefully, those will give you some ideas that will match what you will learn today.

Today I wanted to introduce a little product that I’ve created in the last few weeks called Dashimo. It doesn’t cover everything I wanted from it (feature wise), but it already can be used in production. Therefore, I thought it would be a good idea to get some feedback on whether I should spend some more time on it or throw it in the dumpster. Dashimo joins it’s older brother Statusimo of PowerShell modules allowing an easy way to build HTML output. If it will feel familiar, it’s because it was inspired with Bradley Wyatt PowerShell script he did. It gave me the idea of how I would like to build something similar but in a bit different way then he did, with much more flexibility. Still, if it wasn’t for him, the idea wouldn’t be there, therefore you should send him your thanks.