Microsoft breaks geolocation, locking users out of Azure and M365 Microsoft has found a new and interesting way to break its cloud services: by messing up geolocation services and sending its users to Uzbekistan, which made it impossible for them to log in. The Beast of Redmond let the world know about the mess with this oblique tweet regarding Microsoft 365: We're investigating an issue …
Across all their product lines. I reported a bug in Visual Studio (a debug window no longer reopening at its last size and position). After asking for more information (which I provided). They changed my report to a feature request. Then they closed it because it was 'out of scope with our general product direction'. Despite requests for more information there have been no further responses.
No wonder VS is in the state it is.
When IE11 came out Microsoft wrote a set of group policies for Server 2008 that was incompatible with IE10 and prior, to the extent that installing IE11 would totally overwrite the policies UI for IE10.
Unfortunately, IE11 didn't run on all versions of Windows, so if you had some legacy machines knocking about you had to go through this crazy process of uninstalling IE11 on your Server 2008 DC (with a subsequent reboot!) to make changes to the IE10 policies (and then reinstalling IE11 and another reboot to make the IE11 policies reappear).
The fix for this is logged as a support request. To the best of my knowledge, it still hasn't been fixed.
That actually makes reasonable sense. It's a rather impolite way of communicating, but the burden of it is: "This feature was considered unimportant to our core functionality and has been discontinued, as of a recent change which we might be able to work out if we could be bothered but frankly it sounds like too much work".
Once again, fat-fingered keyboarding without proper checking results in massive pain for many people.
Ah, to think that, in the good ol' days, if a sysadmin goofed it would only affect the users of that company's network.
Today's sysadmins can affect people all across the globe.
Yay progress.
Is there no end to the number of total cock-ups that Microsoft will inflict upon their paying customers due to their infamous lack of QA testing?
As someone who was hit by the Defender icon and program mess a few weeks ago, I have decided that my next main PC will be Linux based and, if I need to run Windows at all, it will be done via a virtual machine. I haven't used MS Office for years, and refuse to have anything to do with their shonky cloud services.
There will come a point when I will be glad to be completely Microsoft- (and Google-) free.
NHS shows this lasted around 3 days, from 21/3 to 24/3
https://support.nhs.net/2023/03/microsoft-365-alert-service-degradation-microsoft-365-suite-some-users-with-conditional-access-policies-may-be-unable-to-access-any-microsoft-365-service/
Why (oh why oh why??) would MS base access on IP numbers? 16 years ago I was fire-fighting email because MS was using unregistered IPs to send mail, and my organization's policy was to drop anything which failed reverse-DNS. I was logging whole banks of intraceable IPs (yet some were clean, so the problem seemed "random", depending on luck of the draw at the email load-levelers). Not my job either way, I was just caught in the middle between angry senders and angry non-recipients.
was fire-fighting email because MS was using unregistered IPs to send mail
That's what the problem really was. Your systems were configured correctly and doing what they should. These days all mail servers should be using IP addresses configured with correct rDNS and some kind of verification protocol. SPF is easy to set up and in conjunction with DMARC (not so easy) provides a useful assurance to recipients. Yes it can occasionally cause problems but that's usually only when someone with a poorly configured mail server tries to send mail and you want those people stopping at the door so that you can dig deeper into who they really are.
Blocking access using an IP whitelist is an effective security measure. It's only a problem when clients are accessing services with dynamic addresses outside of a defined range but you can work around that by making them use a VPN which adds another useful layer of security.
Whoever administrates www.theregister.com is VERY behind the times
ISSUE: None of your web servers has an IPv6 address.
www.theregister.com IPv6 address = None
SOLUTION:
1/ Login to your Cloudflare account.
2/ Click the Network app.
3/ Toggle IPv6 Compatibility On.
ISSUE: Your domain is insecure, because it is not DNSSEC signed.
Domain Registrar for www.theregister.com = CSC Corporate Domains, Inc.
SOLUTION:
1/ Login to your Cloudflare account.
2/ Go to DNS > Settings.
3/ For DNSSEC, click Enable DNSSEC.
(In the dialog, you have access to several necessary values to help you create a DS record at your registrar CSC.)
ISSUE: Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure. TLS 1.1 phase out
SOLUTION
1/ Login to your Cloudflare account.
2/ Go to Domain > “Crypto” tab
3/ choose the “Minimum TLS Version” as TLS 1.2
I dont think this is complicated. get on it.
Some T-Mobile cell pools with 172.59.72.x are listed as Shanghai, CN causing our users to fail because of Conditional Access polices. Our Security teams are investigating numerous instances of "Overseas Travelers" everyday because our T-mobile users are trying to access company resources online and generate alerts.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
