This year, I’m going to pick the most interesting TechCommunity Blog Posts on a weekly basis, and talk about them. There’s so much good content that gets posted and can be missed. This is of course from my point of view and the things I care about, but I hope it’ll help others pick up on some things they might have otherwise missed.
I also have a dedicated Twitter feed that posts all TechCommunity and Azure Blog Posts at https://twitter.com/MSITTechNews if you’d rather see everything.
Here’s my picks:
Yikes, not a great way to start the year off – referred to as the Y2K22 bug, Exchange On-Premises servers (including ones for hybrid) were getting stuck in transport queues and eventually rejecting emails due to a date issue in malware scanning – it didn’t like the year 2022. Amusingly, the fix sets the date on the signature file as December 33rd, 2021 to get around it. The latest CU11 for Exchange 2019 doesn’t fix it, so unlikely other CUs for other versions of Exchange fix it either.
This is about using Quick Assist to remote onto someone’s computer as part of Autopilot. It’s interesting we don’t have a nice native way of remoting into a computer we control still without requiring user input – but it does make sense if the machine is still being configured. It’d be better if one of the first things Autopilot did was allow remote controlling by an administrator without having to talk the user through opening command prompt with key combos and typing in commands.
Using Microsoft Endpoint Manager to deploy Defender to iOS devices without any user input – I love the idea, but this one needs careful planning, testing and communication. What does Defender on iOS actually do? Check out the capabilities such as Web Protection, Threat and Vulnerability Management, and Jailbreak Detection.
A simple post showing an error when trying to enable Advanced Threat Protection (we’re still apparently calling it that because it’s a pain to update everything with constant name changes!) and workaround. I’ve posted there suggesting they have a readable screenshot of the actual error, and put it there in plain text too so it’s searchable.
“New recordings will automatically expire 60 days after they are recorded if no action is taken, except for A1 users who will receive a max 30-day default setting. The 60-day default was chosen because, on average across all tenants, 99%+ of meeting recordings are never watched again after 60 days. However, this setting can be modified if a different expiration timeline is desire”
I’ve gone and turned off the auto-expiring of meeting recordings. Why would I want that? Microsoft’s argument quoted is that people don’t watch them after 60 days 99%+ of the time – except what about the < 1% when you do need it? I only need to lose one meeting to be angry that this setting was ever there. There’s also a slight error in the post:
“To change the default auto-expiration setting for your tenant, go to admin.teams.microsoft.com, navigate to Meetings > Meeting Policies > Add in the left navigation panel”
Add isn’t in the left navigation panel, and we probably shouldn’t be adding a new policy, but instead adjusting the Global (Org-wide default). Creating a new policy that’s not applied to anyone won’t do much :)
I’ve posted the above there and hopefully will get updated.
That’s it for week 1!