Scrolling through my Twitter timeline is a common task to start my day. This morning, a tweet from @BleepinComputer has caught my attention.

Microsoft rolls back decision to block Office macros by default - @sergheihttps://t.co/9BK0slNuEw

— BleepingComputer (@BleepinComputer) July 7, 2022

My first reaction: WHAT. THE. FUCK?! Microsoft added this as feature 88883 in februrary 2022 to the Microsoft 365 roadmap, and I was pretty happy about this feature. Let’s take a look at this change.

Ausnahmsweise ein Blogpost in deutscher Sprache. Grund dafür ist, dass Claudia Kühn und ich seit Januar 2022 einen gemeinsamen Podcast rund um den Themenkomplex Datacenter, Cloud und IT ein. Eine lockere Kaminzimmerrunde in der wir entspannt über unseren Job, und alles was damit zu tun hat, plaudern.

Der Podcast erscheint alle zwei Wochen auf den üblichen Kanälen, oder ihr schaut auf der Homepage des Podcasts vorbei. Lasst gernen einen Kommentar/ Feedback da, und gebt uns eine Bewertung auf iTunes.

This error gets me from time to time, regardless which server vendor, mostly on hosts that were upgraded a couple of times. In this case it was a ESXi host currently running a pretty old build of ESXi 6.7 U3 and my job was the upgrade to 7.0 Update 3c.

If you add a upgrade baseline to the cluster or host, and you try to remediate the host, the task fails with a dependency error. When taking a closer look into the taks details, you were getting told that the task has failed because of a failed dependency, but not which VIB it caused.

A customer used PRTG Network Monitor to notify him in case of account lockouts. This worked quite well until we implemented Admin Tiering. In order to get a mail notification in case of an account lockout, or other security-relevant events in Active Directory, I customized some scripts from my PowerShell dump.

The solution is pretty simple: I used the Task Planner to run a PowerShell script if a specific event id occurs. The events are generated in case of a various number of Active Directory events. You have to enable audit policy to get the needed events in the security event log. Take a look at Microsoft audit policy recommendations and enable what you need. I recommend to enable the stronger settings.

Today I faced an interesting problem. A customer told me that their Exchange 2010, which is currently part of a Exchange cross-forest migration project, has an issue with Outlook Web Access and the Exchange Control Panel. Both web sites fail with a white screen and a single message:

440 Login Timeout

I checked some basics, like certificate, configuration of the virtual directories and I found nothing suspicious. Most hints on the internet pointed towards problems with the IUSR_servername user, which is not used with IIS 7 and later. But authentication configuration and filesystem permissions were okay. Also the IIS end event logs were pretty unhelpful.

As part of a Office 365 tenant rebuild, I had to move a custom domain to the new Office 365 tenant. The old tenant was not needed anymore, and the customer had to move to a Non-Profit tenant for compliance reasons. So the migration itself was no big deal:

• disable AzureAD sync
• change UPN of all users
• remove the domain
• connect the domain to the new tenant
• setup a new AzureAD sync
• assign licenses
• time for a beer

That was my, honestly, naive plan for this migration.

EDIT: It seems that his was fixed in vCenter 7.0 U3.

While debugging a vCener Lifecycle Manager, which was unable to download updates, I’ve stumbled over a weird behaviour, which is (IMHO) by design.

Some of you might use a proxy server. And some of you might use a proxy server which requires credentials. In my case, my customer uses a Sophos SG appliance as a web proxy server with authentication. The customer creaded a user with a complex password. But I was unable to get a working internet connection.

Its been four month since my last blog post, and the blog frequency was quite low before that. This blog is, to be honest, a giant pile of stuff that has not worked as expected. Okay, some random thoughts or howto’s, but most blog posts are about stuff that failed in some way. That’s a bit “depressing”. I should write more about the fun things in my life

For a pretty long time my focus was on infrastructure. And my focus _is_ on infrastrucutre - Networks, lots of storage, virtualization with VMware. And always full stack: Networking, Storage, Servers, Operating System, always with a little focus here and there. Sure, products shifted over time, but in the bigger picture, my focus was always on infrastrucutre and datacenter stuff. No client devices, no end user support, no managed services/ admin tasks, no leadership. Technical stuff and projects. But my focus continued to shift. Microsoft Exchange for example. A product I really hate. Not really infrastructure. But I’m good at it and so I got projects and stuff to do. Or Office 365. Or Microsoft Azure. And since 2013 more leadership tasks. And since January 2020 I held some kind of a higher management position.

Adding a second factor to your authentication is always a good idea. Typically the second factor is a One-Time Password (OTP) or a push notification. But what if you want to allow the login into your Horizon View environment only from specific devices? This implies that you need some kind of second factore that also identifies the device. At this point the arch enemy of many of us comes into play: Certificates!

Today I had to deploy a new vCenter appliance. Nothing fancy, new deployment. Stage 1 was easy, but stage 2 failed several times. I re-deployed the vCenter appliance two times, but as the deployment failed for the third time, I took a look into the logs.

The deployment failed without any error, but it didn’t finished. It stopped during the start of different services without any error.