As we work for our customers, we often find ourselves in a position where we know it's not only our problem but most likely, a lot of people will hit this sooner or later. This Technical Hub provides our customers and us with solutions, scripts, and other information useful for Administrators and, to some degree, for non-technical people.
If you feel this title is very familiar to you it's because I actually have stolen the title from Kevin Marquette. I'm in awe of his posts that take you thru topic from beginning till the end. No splitting, no hiding anything, everything on a plate, in a single post. That's why I've decided to write a post that will take you on a trip on how to work with Event Logs, something that is an internal part of Windows Administration. If you've never worked with Events and you're in IT you most likely should make an effort to find out what it is and how you can eat it.
I've been working with PowerShell for a while now and like with most things I do I've learned it by doing and not by reading. I had a job to do, and since I don't like doing things over and over, I thought it's time to learn and do it in PowerShell. Problem with that approach is that you take bits and pieces from PowerShell scripts online that sometimes do the job but not necessarily pay attention to details. And it's fine. I've learned a lot from reading someone else's work, and I learn something new every day. Hopefully, it will be useful to you to some extent.
Recently I'm doing yet another migration between Office 365 tenants using Bittitan Migration Wizard. It's a great tool and takes away a lot of headaches when dealing with the migration of mailboxes or OneDrive data. Unfortunately, like with many blogs on my website I had to hit yet another error. This time error occurred when I tried to assign User Migration Bundle license to users on the Migration Wizard.
Working as a freelancer is a great thing if you can handle it. Each day, each week something new happens and a new problem shows up on my doorstep. It also means it's almost never boring at your job and you get to play with new stuff. But there's one drawback to this. You're often thrown at the problem, told to fix it but often that's about as much information as you get. It wasn't very different today. I was told to switch Office 365 from ADFS to Password Synchronization. While reasons for this are not really important, the important question here is what is the name of AD Connect server that's responsible for this configuration?
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.