Pracując dla naszych klientów często napotykamy różnego rodzaju problemy, które wymagają rozwiązania. Oczywiście naiwnością było by sądzić, że tylko my lub nasi klienci mają te problemy stąd też powstał pomysł prowadzenia bloga, na którym opisujemy nasze przygody i rozwiązania. Chcąc dotrzeć do jak największego grona ludzi techniczne artykuły są dostępne w większości w języku angielskim. W miarę wolnego czasu postaramy się przetłumaczyć kolejne artykuły.
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.
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.
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:
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.
Recently I was switching Office 365 tenant from ADFS to Azure AD Pass-through authentication (PTA). It all went smoothly with one exception. After removing one of the Azure AD Connect servers and all applications from its Azure AD Connect interface still is showing said agent, just inactive.
A few days ago, I tried to use Install-Module on the old Windows 2008R2 system that I use for specific tasks.
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.
The security account manager (SAM) has determined that the security identifier (SID) for this computer is already in use in the Forest you want to join. This can happen when restoring an Active Directory Domain Controller with an improper backup. Reinstall the operating system on the local AD DC to obtain a new SID.
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.