PowerShellGallery – You are installing modules from an untrusted repository

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.

Everyone now and then, there comes a moment you need to add a user into Administrators group on each computer…

Recently there was this discussion on PowerShell Group on Facebook about issue posted by one user. While the subject doesn’t matter for this post, few people commented on the idea that he was using Format-Table in the middle of the pipeline to do something. They all said Format-Table should be used as last in the pipeline. Otherwise, you would get the wrong output. But should it? Well, it depends!

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.

Have you ever looked at your Active Directory and wondered, „Why do I still have computers listed that haven’t been turned on since World Cup 2016?” Yeah, we’ve all been there. Keeping AD clean and up-to-date is like trying to organize your garage—it’s easy to put off until it becomes a total mess.

We need to deal with a group names through SID’s rather than names because each group name is different in different languages. The second problem is to distinguish whether a user is a local or domain user. Finally, I need to connect to Active Directory to verify if the user I am about to remove has ExtensionAttribute10 (or any other field in AD) filled in or not.

In Active Directory when you change something, it’s replicated to other Domain Controllers regularly. It’s a standard procedure that happens automatically in the background for you. It’s a handy feature because you can have multiple DC’s all over the world and have your users data in sync. You can change almost anything on DC nearest to you and be sure it will be the same value all over the place. But is it always the same? Well, it should be unless it isn’t. Today I was given a new migration from  Exchange to Office 365. I started with ADConnect installation and wanted to make sure that UserPrincipalNames have all UPNSuffixes in place.

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.

A few days ago, I was asked to take a look at PowerShell Malware. While I don’t know much about malware, my curiosity didn’t let me skip on this occasion, and I was handed over WindowsPowerShell.evtx file. Ok, that’s not what I expected! I wanted PowerShell .ps1 files that I can read and assess? Well, you play with the cards you were dealt with. What I was handed over was PowerShell Event Log. PowerShell writes whatever you execute, and it thinks it is risky, to Windows PowerShell Operation Event Log.

Today I saw an article on how to get Windows Version Report from Active Directory and thought that this is a cool idea. Something handy for migration scenarios or information on how up to date is your infrastructure. Since there are many ways to do the same thing I decided to tackle this myself and further include it into PSWinDocumentation.AD project. By default Active Directory stores Operating System and Operating System Version but it doesn’t really show versions one may expect.

I’ve been working today trying to deliver to one of my Clients Active Directory documentation. To my surprise, something that worked fine for a very long time has started to provide weird results. So, after spending about 8 hours taking apart a few of my PowerShell modules trying to find out what is wrong finally, I’ve found it: Export-CliXML / Import-CliXML. Those two commands are great. I’ve used them multiple times with great success (or so I thought).

As you may have seen in my other post, there’s a simple, PowerShell way to get Office 365 Health Service data for you to use any way you like it. But before you can use that, you need to register granular permissions on your Office  365 tenant so that that data is provided to you. Here’s a step by step way to do it.

Active Directory replication is a critical process that ensures the consistent and up-to-date state of directory information across all domain controllers in a domain. Monitoring this process is important as it helps identify any issues that may arise and resolve them quickly. One way to monitor Active Directory replication is by using the Repadmin command-line tool. Repadmin provides a wealth of information about the replication status and health of a domain. However, manually checking the Repadmin output can be time-consuming and tedious, and running it manually every 30 minutes just to check if everything is great doesn’t seem like a great idea. While PowerShell has its own commands around replication I’ve not found something as fast and reliable as repadmin /replsummary.