I’ve been using PowerShell for a long while now using Hashtables, OrderedDictionary, and other types of data types in PowerShell, but I never paid attention to how powerful those are. And I don’t mean your general knowledge about hashtables that is already covered by Kevin Marquette in his article Everything you wanted to know about Hashtables or my article PowerShell – Few tricks about HashTables and Arrays I wish I knew when I started. Let’s find out, how Powerful they are, shall we?
Active Directory
It’s no secret that nobody likes creating documentation. I don’t like it, and you don’t like it, even documentation lovers don’t like it. But while you can live without documentation, you really shouldn’t. And I am not talking here only about documentation that is only useful in the onboarding process of new employees or documentation concerning introducing someone to some concepts to get them easily start. I’m talking about documentation for your live environment where you know what you have, how you have set it up, but is still the same after one week, one month, or one year? Usually, not so much. And one of the worst mistakes admin can do is assume that his environment doesn’t change, things are as they were when they were set up.
While the title of this blog may be a bit exaggeration, the command I’m trying to show here does it’s best to deliver on the promise. What you’re about to witness here is something I’ve worked on for a while now, and it meets my basic needs. If you don’t have SIEM product or products that monitor who does what in Active Directory this command makes it very easy, even for people who don’t have much experience in reading Event Logs. If you’d like to learn about working with Windows Event Logs here’s a great article I wrote recently – PowerShell – Everything you wanted to know about Event Logs and then some.
Having a modern, secure infrastructure in 2019 is a requirement. You should implement BitLocker to make sure that in the event of stolen laptop data is not readily extractable and implementing LAPS is a must in a fast changing IT world. But I’m not here to convince you to those two security features. I’m here to show you an easy way to backup LAPS and BitLocker. While having everything stored in Active Directory is excellent, things can get complicated when you don’t have access to your Active Directory, or you restore an older version of it. You see, LAPS, for example, keeps only last Administrator password. This is great and all but what happens if you restore the machine from backup from 6 months back? Your password has already changed multiple times. During our testing of DR scenarios, we wanted to access the computer via their local Administrator credentials and we just couldn’t because that password was already gone.
Hosting your VM’s in Azure Cloud is excellent. You have all those features, professionally managed and virtually limitless. I don’t want to take your time to sell you Azure Services but to share a solution to one of the things I had to solve in Azure and sooner or later you may end up with on. During the test restore for Active Directory and multiple other machines which were much older (or newer) then Active Directory Domain Controller that was restored it turned out one can’t log in to most of the devices. First of all your domain password is already changed, but that can quickly be addressed. Your second and more significant problem is Network Level Authentication (NLA), and your 3rd problem is broken trust relationship.
I’ve been testing Disaster Recovery scenario restoring Active Directory. One of the servers was restored, and it worked for a moment after restore. If you can regain your Primary DC, it’s best to do so. If you can’t, a standard thing to do during DR is to move all FSMO roles to the restored server so that it can become a master server. You can find out your FSMO holders by using those commands below:
A new branch of PSWinReporting is slowly coming, and I thought it would be the best time to have a final article about it with all configuration options available for those that will want to stay using PSWinReporting from Legacy branch. The idea is that you may have it working in your systems and it’s good enough for you. You may not want to change it, and with New Hope, the changes are so big it’s a rewrite.
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.
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?
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.