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.
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.
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.
As you may know, PowerShell has multiple streams. Write-Output, Write-Error, Write-Warning, Write-Verbose, Write-Debug, and Write-Information. It also has Write-Host which until PowerShell 5 was a bit special. Since PowerShell 5.1 it's a wrapper over Write-Information, so it doesn't kill puppies anymore. While I could spend the next five pages trying to give my best and describe those streams, there are already many articles describing them in detail. Please check the following link if you need that information.
I've been working with PowerShell Modules for a while now, and most of my knowledge about them came from Warren F (psCookieMonster) blog about Building a PowerShell Module. It is a handy piece of information and recommended read for anyone starting up writing PowerShell Modules. He introduces an idea where a module is stored in multiple folders Private, Public, Bin, Lib and so on and having YourModule.psm1 as a wrapper for functions, binaries in those folders, where each function is stored in its file. It's an excellent concept, and I use it every day. It allows me to jump into a file quickly I want to find and fundamentally easier for development, especially in teams.
Last few weeks I'm responsible for migrating from Office 365 to Office 365. Part of this migration process is to set up new Exchange 2016 server that will work as relay instead of using IIS server. I've setup hybrid, added accepted domains, prepared connectors, but there's one thing missing. Any time an email is sent via relay to a user that exists on Office 365 and at the same time exists in Active Directory email never gets there.
MigrationWiz from Bittitan is one of the best tools on the market allowing for migration of user mailboxes. Whether it's a google account, exchange account or IMAP, it will help you out. Last few months I'm part of migration project that is using Bittitan at its core. One of the signature features of this tool is the ability to migrate mailboxes from Office 365 tenant to Office 365 tenant. This is not something that every application can do. Another feature (and something I want to address today) is the ability to ask users for their logins and password to migrate their data from one tenant to another tenant. While in general, you shouldn't do that and you should use migration accounts with proper permissions sometimes you have no other choice.
Azure AD Connect is an application responsible for synchronizing Active Directory with Azure AD allowing for a natural population of users, groups, and devices in Office 365. While for most companies standard setup is very easy and most of the time touch-free, there are companies which require greater customization. During installation of AD Connector, you choose what should be used for Azure AD Username from your AD. UserPrincipalName field is an obvious choice for this and also proposed by default for that purpose. This field is utilized further by your users to log in to your Exchange, SharePoint, Teams and so on.