Windows 10 – You’ll need the internet for this 0xCAA7004 or 0xCAA30194 or 0x80072EFD

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.

Windows 10 was released by Microsoft on July 29th of 2015. Even though several months has already passed, millions of users…

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.

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?

If you’re paying attention to what’s happening around the world now you probably know Have I Been Pwned service by now. You probably know that it has huge lists of hashes of passwords that leaked out over the years from different services (LinkedIn, Adobe, and so on). This means those passwords are now in possession of good guys, but also bad guys. With Active Directory being often a central place to store your password that allows you to access your Office 365 account, ADFS, Microsoft Exchange it’s important that your AD passwords is both secure and safe. Bad guys may want to try and access your email accounts or other data that’s available online. And having a list of passwords you or other people may have used before doesn’t help you in protecting your own data.

When I created ImagePlayground, I thought about how to show its usefulness to the general community. On how to deliver what PowerShell can do. Then I saw on some forum people asking BGInfo to expand and allow running PowerShell scripts so that the data on the BGInfo Wallpaper can be gathered from PowerShell rather than VBS. I thought this was a great idea to create BGInfo using PowerShell without the necessity of using BGInfo at all.

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.

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.