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.
One of the critical parts of Active Directory is DFS. It allows you to share same NETLOGON/SYSVOL folders across all Domain Controllers in your Forest. Its health is vital to the functionality of your Active Directory. If it's broken, a lot of things may not work, and it's not that easy to tell the status of it. At first sight, everything may seem to work correctly, but if you take a closer look – not so much. It's great if you find it out by yourself, but not fun if suddenly GPO's don't apply to some users, computers, and you find out a year later.
I've been in IT for a longer time now. I've made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.
Recently I was testing renaming the NETBIOS name of an Active Directory domain. While this process is fairly easy, there are a few gotcha's, and before one would like to rename their domain or NETBIOS name, serious testing is required to be sure everything works after rename. In the end, if something goes wrong, the rollback will not be a walk in a park. It will hurt, and it will eat your time. So there was I going thru the usual steps.
In March 2020, Microsoft will release its monthly updates. With those updates, Microsoft will disable insecure LDAP Bindings, which is going to break a lot of your systems (hopefully not). But this was already communicated, and you know all about it, right? If not, you should read those two articles that can help you with understanding what is happening and when.
It's year 2020 and 365 days passed since my last year blog post about PowerShell modules I worked on in 2018. I thought it would be a good occasion to review what happened and how things changed during that time. When I wrote the last blog post in the first days of 2019, my PowerShell modules were downloaded just a bit over 15000 times. Fast Forward today, and the counter is at 280000 times spread over 40 modules. Of course, not all those modules are equal. In 2019 I created multiple new PowerShell modules, but some modules were archived, while others were migrated back to their “parents”. Just to see how my community road was going in the last years I decided to check some statistics.
Reading Event Logs is something that every admin does or at least should do quite often. When writing PowerShell scripts, you often need to read event logs to find out different things across your infrastructure. But now and then it's quite the opposite. You need to write something to Event Log so it can be recorded for the future. Sure, you can write your information to log files, but since Windows already has a built-in logging system, it may be much easier to write stuff to event log. This allows you to centralize your event logs and processed by specialized tools like SIEM.
We're in the last days of 2019, and this will be my last blog post this year. What better way to end a good year than with the release of the new PowerShell module. If the title of today's blog post isn't giving it up yet, I wanted to share a PowerShell module called PSWritePDF that can help you create and modify (split/merge) PDF documents. It joins my other PowerShell modules to create different types of documents such as PSWriteWord, PSWriteExcel, PSWriteHTML. I know that PSWriteExcel is relatively basic, but both PSWriteHTML and PSWriteWord deliver robust build capabilities.
Christmas time is upon us, and I've decided that my PSTeams module needs some love. I wrote it in late 2018 and updated it a few times at the beginning of 2019. This release hopefully is worth of having 1.0 version number. I don't do that often and usually go for build numbers changes only, but Microsoft Teams message cards have their limits on functionality. Therefore, there are not many things that can be added unless Microsoft opens up and gives us all the cool features of Adaptive Cards. PSTeams module uses Webconnector to send messages to Teams. That method only supports Message Cards, which even Microsoft calls Legacy. But legacy doesn't mean fully functional with some cool features of their own. If you're new to PSTeams you may want to read those 2 posts below to get information how to set it up.
In the last few days, I've got two reports that my PowerShell module for Office 365 Health suddenly started giving errors. This was a bit weird because it worked perfectly fine on my end. But while I could understand one person having an issue of their own, with their network or firewalls, if the second person comes along with the same report, that means something else is going on.
Some time ago I've wrote PowerShell way to get all information about Office 365 Service Health, and if you were thinking that I would try the same concept for Azure Services you were right. However, I failed. This is because Office 365 Health can be gathered using Microsoft Graph API, and Azure Health information, as far as I know, is not available in the form I wanted it. Azure Status is available as part of Azure Status website. Contrary to Office 365 health you don't have to login to your Office 365 tenant to read it.