windows
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.
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?
I’ve been working today on a little project when suddenly my modules stopped working. It was weird because I have not touched anything that could cause it. A message was a bit cryptic mentioning that my PSWriteColor module is required but not available. I’ve decided to try and load PSWriteColor manually using Import-Module command.
During synchronization of Active Directory with Office 365 via Azure AD Connect I was greeted with a list of accounts that have permission-issue. Error message by itself gives you a slight hint, but it doesn’t tell you exactly where to look.
Recently I had a weird case where one of our Azure servers was starting losing space pretty quickly making Pulseway go nuts. As you can assume from the title of this post the cause for this is Azure Agent itself. But before I actually knew that I had to do some digging as it’s not that obvious because Windows Explorer isn’t showing anything worth checking.
23 Nov: Outlook – The primary account cannot be removed unless it is the only account in the profile
Last few months I’m responsible for the migration of Office 365 to Office 365. While doing so, we came into a situation where users have their old mailbox as Primary Account and new Mailbox as their secondary account. This is a quite common scenario that people are running into and something that is expected. Usually, my recommendation is: Please create a new profile for user and topic is closed. It’s also quite easy to achieve this in an automated way where you delete all profiles and Outlook just goes with autodiscovery adding new account as required. That’s how I have always done this till now. My Client has gone thru setting up 1000+ users with their second account in Outlook and deleting a whole profile, recreating would cause lots of downloading of emails from Office 365 that my Client wanted to avoid.
It’s been less than 24 hours since I’ve released PSBlackListChecker with support, among other improvements, for Microsoft Teams and Slack and I’m now adding Discord to the mix. Discord was a popular request (well not really, just one person asked, but let’s pretend everyone loves PSBlackListChecker so much that they are too shy to ask for feature requests!).
