Posts by Trixr 592 publicly visible posts • joined 30 Jun 2009
...Until your file server runs out of work queues and silently grinds to a halt. It might be fine if you are in a relatively small org where it's just a few dozen employees that have PST files permanently open for write. Not great if you have 1000s accessing the same storage volumes.
Also, the way those things get corrupted if you just look at them sideways. No thanks.
I am *currently* working in an organisation (also in Australia, ironically) where the default server build - deployed as the baseline on every server - included IIS until literally this year. I had kicked up a fuss about it for at least 2-3 years until I finally convinced the sec team to take an interest.
Of course, nothing has been done about the 100s of existing servers still running IIS services for no reason.
Discord is great. Not perfect, but way better than Teams. Unless you love "quick links" to stupid apps that you can easily reach via the taskbar or quick-launch anyway. And of course Teams is integrated into the Office apps - some people apparently like Sharepoint. I don't. If you want an actual messaging client, rather than a messaging bolt-on to SPO, that's where Discord is powerful.
Slack is good if it's extended with the tons of add-ons that are available. Remember, Teams' ethos was basically to copy Slack and slap it on top of Sharepoint + Skype/Lync and now jam in Yammer. Also, in Slack, message search actually works - you get the results AND you can click on a message and be taken to the actual position in the thread. Same with Discord, of course.
Yeah, they're trying to position it to shoehorn Yammer back in, that PoS.
The UI actually looks better to my eyes (the current one is just shite), and the search is somewhat more responsive.
BUT, there is still no convenient way to search your own messages (you still have to type "from: [your.full.email]", and even worse, you STILL can't click on a search result and be taken to the message position, if it's more than a couple of "pages" of messages away. Useless.
And also how it's only been in relatively recent years that IT has broadened out so much in terms of specialities. A lot of people in their 50s and up would have gotten into the profession when you had four people (max) running the main university server farm, plus maybe a couple of people doing student support. Maybe one or two running per-department servers. Try doing that with less than several dozen staff now.
There really weren't that many jobs - I certainly didn't think of it as an option in my late teens/early 20s. People that did were heavily into maths, EE, or had a family member into computing. The whole focus of computing degrees was on programming or low-level hardware stuff.
Nope, I'm 54, and there was no such thing as an IT degree when I first started uni. There was "Computer Science" as part of the Mathematics department, but since I hadn't done any advanced maths at high school, it didn't even cross my mind.
I didn't get into IT until I got made redundant from my first career, late 90s. Still don't have an IT-related degree (some professional certifications, sure).
Co-signed. Exchange 2010 was fine, and 2016 was when everything you wanted in terms of HA and so on worked very nicely. I had more uptime over my 16 years managing Exchange on-prem than MSFT has managed to achieve for one calendar year in the APAC region.
I had one server stop delivering mail for about 6 hours - small region, about 10% of the user base (fixed with a stinking reboot, after exhausting every other troubleshooting option). And that is literally all, other than dodgy CUs, as you say.
No, I'm sorry, Kerberos is a core technology in the AD stack. While MSFT making moves to tighten up their entire auth structure is commendable, it is only in the last year - in fact, since November last year - that they have released so many updates that have screwed up one or other component of AD auth (NTLM/Kerberos - LDAP stuff has been fine).
This is *entirely* due to whatever testing model they have implemented most recently, which I understand is essentially relying on the Insider program for "regression testing".
I expect some pain while we ensure that legacy accounts get remediated prior to force-deprecating RC4, and the documented staged approach to do that via these updates is fine. But you cannot break core services simply because you can't be bothered regression-testing - it is not a new concept, and nor is it an obsolete one.
AD security has always been highly complex and has undergone significant changes in the last 20 years, mostly without too much disruption. But this past year has been more like the mid-90s days of bad NT4 service packs. It's really not acceptable, unless you subscribe to the view that this is a deliberate ploy to force everyone into cloud, which frankly seems increasingly likely to me.
Of course, debacles like these mean that our clients are even more reluctant to do even basic timely updates, let alone migrate if it makes sense for their workloads (which, frankly, it doesn't always).
Really. I don't see in the Kerberos v5 spec where it states the 300s clock skew is MS-specific: https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html. Also, like other OSes, the acceptable skew for Kerberos auth is customisable in Windows, down to 60s.
And I don't care what OS you're running; you're not configuring a Kerberos environment correctly if you're not using an NTP service to coordinate your system times. As MSFT doco specifically states should be done when setting up an AD environment, complete with a time service embedded into all Active Directory implementations that all clients will synchronise to by default.
Up until Win 6.3, the acceptable time drift on clients was not defined. In practice, it was up to a couple of seconds (you could install third-party higher-precision NTP clients). More recent versions of Windows allow you to specify max time drift from 1s down to 1ms (the latter with expected constraints - no more than 4 hops and 0.1ms network latency between client and stratum 4 or higher time source, avg daily CPU time <80%)
In any case, if you have Windows machines in a domain hierarchy getting time from VM hosts, you've done it wrong. I totally accept that Windows/AD is not perfect, but if you're going to snipe at it, at least get your facts correct.
We didn't see any Azure-related errors in our environments - we got the known error Event ID 14 in System log on DCs that had been patched without the fix yet and a problem account:
"While processing an AS request for target service krbtgt, the account [ACCOUNT] did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 23 24 -135 3. The accounts available etypes : 23 18 17. Changing or resetting the password of [ACCOUNT] will generate a proper key.
This was a service account where the "This account supports AES-256 encryption" option had been set. So I unchecked the option on the account and made sure that msDS-SupportedEncryptionTypes was set to 0. That fixed the problem for that account while we applied fixes to the DCs.
If you're getting Event 42 errors, that needs the KRBTGT password to be reset: https://dirteam.com/sander/2022/11/09/knowledgebase-you-experience-errors-with-event-id-42-and-source-kdcsvc-on-domain-controllers/
And don't worry, I too feel like this is part of MSFT's ongoing campaign to stealth-deprecate on-prem AD, but I wish they'd just accept that in the real world, some of us don't want to put ALL our eggs in the cloud basket. Especially if you're running critical public infrastructure.
This kind of thing makes it more difficult for IT teams to convince the nervous that no, we DO need to apply security updates regularly, and yes, we DO need to update these 20-year-old systems before they fall over, since no-one is supporting either the hardware or OS.
Also time to change your KRBTGT password (twice, after allowing replication time to all DCs or 10 hours to be safe (krb token expiry interval)) if it hasn't been done since Server 2008 DCs were introduced in the environment. Helpful hint: the WhenCreated date of the "Read-only Domain Controllers" group tells you when. Otherwise KRBTGT won't have AES crypto keys.
The domain needs to be at least the 2008 DFL first. The safest method is to use the New-KrbtgtKeys.ps1 script by Microsoft, available on Github, since it does a single-item replication to all DCs that finishes in seconds in our environment.
Any other accounts (i.e. service accounts) with passwords that haven't been changed since then need to be rotated too. Yes, I got an unfortunate surprise when I queried our domains for the number of active accounts in that boat.
The whole mission of these updates is to deprecate RC4, eventually. It'd be nice if MSFT didn't screw up any further updates, like they seem to have with every single Kerb/NTLM update since late last year.
I'll raise your mid-90s Vines with the fact I recently found a bunch of 2019 servers running the computer! browser! service in our AD. Some numpty had enabled SMB1 in the build, and by default, it enables Computer Browser. The legacy build procedure that disabled it was not applied to the newer boxes.
I noticed because I was idling through the SMB audit logs and found a load of servers yelling at each other for network browser elections.
I'm old enough that I grew up with stones for a while, and I still need to mentally convert people's heights, but honestly, I barely know stones equate to anymore (it's a bit over 6kg, fwiw). At least with pounds, you can divide by 2 and knock off 20%-ish for a rough idea.
The thing that really gets up my nose with Brits and their "revolutionary times measurements" snarks at the Americans is their insistence on imperial measurements for road distances!! It drove me nuts (literally) when I lived there, and all their feeble BS about it "costs too much" to change road signs etc is just that, BS. All their former colonies managed it in the 60s/70s. India, being a large country both in area and population, made the full metric transition in 5 years.
I'm sure the only reason car manufacturers aren't jumping up and down about having to provide speedos and odometers etc in miles is because of the American market enabling it. So really, the Brits should be grateful to them.
Guy Fawkes Day?
This fake outrage about "holidays" not just being Christmas is just getting very, very, very tedious. I've worked more xmases than not, because neither I nor my family are Christians - we're "nothing at all".
"Holiday season" implies all the holidays around the end of the year, such as New Year's Day (even if you're so bigoted as to believe the other religious solstice-ish holidays don't "count"). It's disingenuous to pretend it doesn't - it's been common usage since before all this BS about "PC language" hit the Daily Fail and its like.
If you only count Xmas Day/Boxing Day as holidays - no "season" for you - and you don't take New Year's Day off, oh well, your loss.
Oh no, this is sad news. I first heard about the Booths when I worked at Birkbeck College around the turn of the millennium, and they created a small but mighty computer science department there in the 1950s (to go with the small but mighty College).
As the only female sysadmin working there at the time and one of very few at the University of London in general, she was an inspirational figure. She built those early machines (with her colleages), plus all those other achievements in programming.
Or when a tech in the UK removes the shrink-wrap from a replacement PSU freshly-shipped from the US (yes, I'm that old, basic parts were still sometimes manufactured there at the time) and installs it into the PC without checking the voltage switch is set to 240V. (And yes, it wasn't a nominal 230V at the time either.)
Poor guy was the first tech on site after the workplace had negotiated new kit from a large US-based vendor, with full hardware support. Previously we'd done "return to base" for the really gnarly faults in equipment supplied by the previous UK-based manufacturer. It probably didn't help there were at least four of us standing around observing the new support arrangement in operation.
To give us credit, none of us laughed out loud at the loud BANG! and resultant billow of Magic Smoke. I think one of us gently suggested the voltage switch as the probable root cause while he looked on in shock. Motherboard, CPU and memory plus PSU were duly replaced with no further excitement a day later, ISTR.
Yes, the message I was getting loud and strong was that "bad actors" is probably not going to apply to any country's duly-appointed military. Maybe not even to military forces engaged by the "right" nationstates - mercs, sorry, "contractors", are hired by various governments all the time.
And that wasn't the only prevaricating phrase in that statement.
It's true that attempts at "corrective" engineering of entire biosystems never seem to end well.
One sensible initiative recently is the creation of waste traps where waterways exit to the ocean - I hope these scale up rapidly around the world. It's a lot easier to "harvest" and process the plastic if you're not in the middle of the ocean. The more any such interception takes place "upstream" (in the literal and figurative senses), the better.
As alluded to above, it doesn't mean that we can take our eye off the ball when it comes to restricting the types of plastic products that most readily end up being discarded in the environment. There's also the not-insignificant issue of fossil fuels being used to produce them, although that's slightly better than simply sending them up in smoke.
But at least it'd solve a large part of the problem of disposal, if it works as it promises to, including the ridiculous current situation of literally shipping garbage all over the world.
Worked at a university college in the early 2000s where A Certain Academic had the habit of using the terminator that exited by his desk at a convenient height as a coat hook. Over time, the terminator would loosen from the movement of his jacket being hung and removed.
Cue about once a year or so of screams from an entire building as it went offline when Prof X donned his jacket and went to lunch, or on one fun occasion, left late one day, and no-one noticed until the next morning. He did eventually stroll in the next morning before one of the facilities custodians turned up with the office key, but only by minutes.
One of the varieties they're most hyped about at present requires some specific nutrients and 120 C temps in a kind of "cooker" (controlled digestion container) to really get into gear.
Maybe the inside of our homes will reach those temps in the next few decades anyway, but here's hoping not.
Given that much of that waste is due to manufacturing goods for Western nations or disposing of our junk, I think it's a bit disingenuous to insist it's "not ours". I'd say a good chunk of it is in fact ours, indirectly.
Australia exports over three-quarters of the coal it digs up. A lot of it to power those overseas factories churning out that stuff we'll eventually consume. We don't get off lightly in either of those equations.
It used to be MS Mail (meh) and Schedule+, so merging those products was indeed a good thing to do. Also, resource calendars are a handy thing that were facilitated by the merge.
While early Exchange was still pants, it got incrementally better over time, and I think Exchange 2016 was pretty great. At least before they started "encouraging" everyone into Exchange Online.
Yes, totally agree. Just because a translation is older and has "ye" in it, it isn't necessarily any more accurate.
And while an idiosyncratic word order might be more "poetic" in English sometimes, there's no point doing that if the original doesn't have a distinctive tense or style that you're trying to echo.
One of my pet peeves is older translations of non-European languages that are full of "thee" and "thou" when the source language never had a distinction between the formal or informal "you". But translators thought it sounded more "exotic", so that's how they rendered it.
If it's anything like where I work, yes, it is being backed up. Into a backup which has never been tested, while the backup account is an AD Domain Admin.
I was actually shocked to find that the DB service didn't use the same cred. No, the "SQLService" account is running ALL the DBs in the entire org, multiple DB farms, scores of servers and applications.
Yes, I have got copies of the emails where I've pointed this out at length to managers and security team, multiple times.
See, that's Ethernet's USP - just make broadcast 'storms' into a protocol feature.
I do not have found memories of token ring, nor the place that would have networks going around a couple of floors, then up and down between floors (16 floors, two adjacent buildings), so you'd never know which network the token was "lost" from when something when down. (At least, not as a lowly desktop support peon.)
Then those crappy IBM "gender neutral" connectors that'd fall apart if there was a stiff breeze from rolling your chair forward... There was some plastic device that'd make them more difficult to kick apart, apparently, but we never got those.
Exactly. Saying, "music sounds better from the player attached to your sound system via a cable than from a radio station, doesn't it? Same with data transmission over phone lines vs satellite" isn't that hard.
I don't doubt that the owner was an absolute arseh*le, but it's always better when the tech helps themselves first (and any other techs saddled with the client subsequently) by at least attempting the reasonable explanation once and not going out of their way to piss said owner off when they're fundamentally asking "why is it different here?"
Of course it's glaringly obvious to anyone who's dealt with this stuff, or even tuned a radio, but when they're a rich prat who's had everything supplied on-tap - especially people who never had to earn their wealth doing real work - there are going to be "knowledge gaps".
There's nothing worse than dealing with "demanding customers" (aka rich prats), though, especially when travel and fatigue are factors - we can all can end up in this kind of situation where the filters go off when confronted with rudeness and the blindingly obvious.
They've almost succeeded with getting rid of on-prem Exchange with their diligent work on b0rked CUs in the last several years. Since November last year, they seem to be getting into high gear with stealth-deprecating Active Directory too.
I think every major AD-related update since then has had issues. And that's not counting Server 2022, every month's update for those seems to have something that screws up some AD-related service (me, to boss re deploying 2022 DCs: "NOT YET").
If you know what they did with actually-useful WindowsUpdate.log by ditching the text and converting it to some mystery binary format (probably this one) that could not be read by any of their existing tools (like Message Analyser), and requires a stinking powershell command (the command, not powershell) to convert into a readable format, meaning it can't be tailed in real time, this is 100% no surprise whatsoever.
I wonder if this will stop MSFT inventing all manner of logs that are unreadable by consumers, are also apparently zero use for diagnostics (never once had a support engineer request anything of that nature, admittedly I don't work with desktop systems), and which consume considerable amounts of space at times. I get the need for faster logging at times, but the ETL type should be very limited in size and meaningful output sent to the existing event logs (zillions of those these days too) or a text file.
Including some of their monitoring apps, like the ATP sensor service. One of them DOES log to a text file, and seemingly is a spew of all the .NET activity inside the app with absolutely no way of configuring it to "error only" or something that doesn't churn away constantly.
Exactly. Talk to an archivist any time about how many works have been lost over the centuries due to fire, mould, moths, rot, etc etc etc etc. Which recording company was it that recently had all their pre-70s (?) masters go up in flames when a single warehouse burned down? Film on nitrate stock is literally disintegrating as time goes on, where it's not spontaneously combusting.
A lot of library/archive budgets these days have chunks set aside for digitisation projects, and there are a lot of very good reasons why that's happening.
These days, at least we've got a better grasp of digital formats, we aren't so reliant on physical storage media (at least not in the sense of the one copy being archived on a laser disk or whatever), and people in the biz understand the importance of transferring files to new formats as required.
Um, why wasn't the printer rendering her document? Why on earth would Word be a better option if the organisation worked with both document types? Especially since WP was apparently on the machine.
As written, I have to say this sounds like more of a support issue than a user one. Perhaps there was a user issue in that the WP document was in letter size and the printer had A4 paper or something, but that would not have been solved by Word. Or your troubleshooting, as described.
I worked in a place in the late 90s where the secretaries knew perfectly well they had to reboot if a machine locked up (memory issues due to awful Word macros after transferring docs from word perfect), but they would lie about having done so.
So for the more senior ones where it was not worth arguing with them, I had a routine where I would visit, open a dos prompt and run dir /s, let it run though all the file listings, THEN reboot the machine. Some of them subsequently sent notes to my boss praising my "responsive support" and how their machines were "much more reliable" after one of my visits. More than one way to skin a cat. Wish we'd had remote support!
I'm not anal about many things, but the most minimal vampire power draw and/or standby lights on devices that go unused for more than a day drive me absolutely bonkers, even if it's mere cents per annum to run. So that'd be my solution too (IRL, I refuse to have a printer in the home - they hate me and I hate them).
I'm no great fan of Macs myself, but yes, I was eyerolling throughout at the tone of "boo hoo, this one tool doesn't work on this device".
If there's additional context as to why Macs are underperforming when it comes to AV processing in geneal, it's missing from this piece.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
