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.
Today's story happened a few days back to me, and I think many people may not even know about some object behaviors in PowerShell (just like me). I know some of you may think this is basic PowerShell knowledge but even thou I've written a lot of different PowerShell modules I kind of skipped basics. That means I often find myself struggling with something that's obvious if you've done your due diligence before starting to work with the code. But that's typical me, playing with complicated stuff, failing at simple things.
Working with Office 365 is my bread and butter in the last few months. I'm a System Architect and I am dropped in multiple projects, both new and old, to fix certain aspect and get out before anyone sees me. One of the common tasks I get is to provide some data about users stored in Office 365.
I've been working with Windows Events for a while now. One of the things I did to help me diagnose problems and reporting on Windows Events was to write PSEventViewer to help to parse the logs and write PSWinReporting to help monitor (with use of PSEventViewer) Domain Controllers for events that happen across the domain. It's handy and I, get those excellent daily reports of what happened while I was gone.
I must admit that it was a bit embarrassing to see my Administrator password expired when I tried to log in as Domain Admin to Domain Controller. I got this little message saying This user account's password has expired. The password must change to logon. Please update the password or contact your system administrator or technical support.
Windows Server 2019 is out now for a couple of months now, and some of you may be interested in playing with it. When you first install it, you can test it for 180 days (so-called Grace Period) after which you need to activate it with a proper production license.
We're a few days in 2019, and from a time perspective, I can say I had a busy 2018. I must say I've never expected that but in 2018 I've created or worked on 24 PowerShell modules. Some were simpler ones, some were a bit more advanced, and some will be retired in 2019 because their features will be moved to other modules. In PowerShellGallery alone those were downloaded over 15000 times (I must admit that some of those are surely automated tests – “Hello Pester” that I've learned in 2018. It's a nice number thou, and something I'm kind of proud of myself. After all, before 2018 I've not created a single PowerShell module before. Sure, I've created a bunch of scripts, hardcoded, that did the task that I had to solve. But I've never before built something, that could be installed by one little command Install-Module (something I've learned in 2018 as well) and executed by anyone, anywhere. I know the title says Sixteen PowerShell Modules but some modules are just too simple to give them anything else than a small mention.
When working with Active Directory one of the common tasks is to move FSMO roles between servers. Well, maybe not that common but it happens from time to time where you have to move all or just some of the FSMO roles. For that purposes, there is single PowerShell command Move-ADDirectoryServerOperationalMasterRole. Sure you can do this via GUI but if there's one command available to fix it all why bother? To make the move one has to be a Domain Admin, Enterprise Admin and Schema Admin. Everything was going smoothly for some roles but wasn't working for others.
Another day, another issue one may say. Today I wanted to install one of my modules to a new server and was greeted with a well-known message (it may seem on first look): A command with name ” is already available on this system. This module ‘PSEventViewer' may override the existing commands. If you still want to install this module ‘PSEventViewer', use -AllowClobber parameter.
Today I've been setting up a new server on Windows 2019. By default, I install Windows with English version even if Client works in their language such as German, Polish or Swedish. While some people install Windows in a language they desire to work with, years of experience taught me that installing English and then adding Language Pack is the best way to go. All errors, windows events, and general troubleshooting is much easier if those are in the native English language. Each version of Windows made it easier to install the language pack and have that up and running in no time. In Windows 2019 it's even more comfortable… or is it?