Przemyslaw Klys

img_5ed5f518efd15

02 cze: Using Win32_UserAccount WMI filter in PowerShell/Group Policies and what to avoid

Some months ago, I created PowerShell Script to create local administrative users on workstations – Create a local user or administrator account in Windows using PowerShell. It’s a bit overcomplicated, but the goal was it should work for Windows 7 and up, and that means supporting PowerShell 2.0. As part of that exercise, I’ve been using Win32_UserAccount WMI based query to find local users and manage them to an extent. While Get-LocalUser exists, it’s not suitable for the PowerShell 2.0 scenario. I also use the same query in GPO for WMI filtering. You can say it’s been a good friend of mine.
Pester V5

28 maj: Converting Pester V4 to Pester V5 basics

Now that Pester V5 is out, I decided that I need to make sure that my Pester tests for all my modules keep on running correctly. Some substantial changes in Pester add new features, changing some things, but that also means all the tests that you have defined most likely will need a small push to get it up and running again on Pester V5. Starting this blog post, I wanted to mention that I am by no means an expert on Pester, but I do use it for some time now for most of my projects.  I am using basic functionality, but even that basic functionality stops working once you upgrade from PesterV4 to PesterV5, so I thought I would save you some time and give you a small overview of how you can quickly fix it. It works for me, but you may have to find your way to fix things.
PowerShellBlack

15 maj: Get-ADObject : The server has returned the following error: invalid enumeration context.

In the last weeks, I’m working on a PowerShell module that the main goal is to work on gathering and fixing GPOs. I’ve been testing my module a lot of times on my test environment, and it worked fine till the moment I run it on production, and it started to fail pretty quickly. The difference between my environment and production is 25 GPOs vs. 5000 GPOs. The error I was getting:
img_5eb54b7b8fe54

08 maj: Getting Verified badge next to your GitHub commits in VS Code

A bit over two years ago, I started posting my PowerShell code as modules on GitHub. Initially, I planned to have them hosted on my website, but few people asked to post it there, and they were right. It would be fairly hard for me to keep my code up to date on my website and, at the same time, let people submit bug reports or help with some PR. It was the right decision! Now that I’ve worked for over two years on GitHub as a daily driver, I wanted to get a new green badge that’s shown on GitHub when you edit some code. I don’t know if you ever noticed, but if you write any code, text file directly via the GitHub.com webpage, your commits always have Verified badge next to them.
img_5e89cc6b4b3e9

07 kwi: Office 365 – Limiting license to minimum apps required

Office 365 has a lot of options and applications to choose from. Enabling one E1, E3, or any other license gives the user a lot of features, including Exchange, SharePoint, and Teams. But what if you want to make sure that the user can access only Microsoft Teams? By default, you can do it manually during the assignment of the license. Simply choose only Apps you want to assign to a user.
img_5e5255c051763

24 lut: AzureAD – Enable Password Expiration with Password Hash Synchronization

Azure AD Connect allows three ways to make sure the user password is the same in Active Directory and Office 365. Those are Password Hash Sync, Pass-Thru Authentication, and ADFS. While my preferred option to go with would be Pass-Thru Authentication, only Password Hash Synchronization is the easiest and least resource-intensive. It synchronizes user password to Office 365, and even if your Active Directory is down, you can still log in to Office 365. It’s perfect for small and even more significant companies that don’t have resources or can’t guarantee that their infrastructure will stay 100% time online so users can authenticate based on their Active Directory.