Just so no one's led astray if they find this in the future, I think the Schannel change is a red herring...I found some other systems with the same errors that hadn't had that cipher disabled.
what did you learn today? (part 2)
- Thread starter continuum
- Start date
January appears to be Windows Shenanigans Month. The cumulative update seems to be having trouble downloading/installing automatically on Server 2012R2 systems (gets stuck at 95% complete), and there also seems to be an iffy Defender update that causes high CPU usage and similar update installation problems.
Those Eaton 9PXPPDU1s make moving a UPS from a 208v facility to a 240v facility really east. Two screws and kick a switch over.
Also, getting rid of another APC UPS makes me happy.
Also, getting rid of another APC UPS makes me happy.
This one is more of a curiosity, and it's related to personal use.
We have a computer hooked up to a TV at home. My Windows account is hooked up to my Microsoft account and has a PIN set. My partner's Windows account a local account with no password. Don't worry it's not admin.
TIL I learned that if my account is signed in, my partner can't use her account. She gets a message when clicking Sign In that her account doesn't meet the password complexity policy. Yes, it's the exact message you get when you try to go change your password and it doesn't mean the domain password policy.
If I go sign out my Windows account, then she can sign into her Windows account.
Very interesting that there's somehow a system wide policy in effect only when a certain user is logged in.
We have a computer hooked up to a TV at home. My Windows account is hooked up to my Microsoft account and has a PIN set. My partner's Windows account a local account with no password. Don't worry it's not admin.
TIL I learned that if my account is signed in, my partner can't use her account. She gets a message when clicking Sign In that her account doesn't meet the password complexity policy. Yes, it's the exact message you get when you try to go change your password and it doesn't mean the domain password policy.
If I go sign out my Windows account, then she can sign into her Windows account.
Very interesting that there's somehow a system wide policy in effect only when a certain user is logged in.
Is it me or are Juniper EX2300s (specifically EX2300- 48MPs in a virtual chassis) really slow to commit?
Is "your Microsoft account" associated with work or school, or is it a personal account?
It's not just you, commits on junos are slow in general, but entry-level switches are really bad about it. It's like they spec them with the junkiest grade of flash memory known to man, and then put in only the bare minimum of it, so that version upgrades on a brand new switch fail with "insufficient storage" unless you resort to trickery.
They're brutal. At first I thought it was because I had transfer on commit enabled, but they're just brutally slow. Fortunately I don't have to touch these switches all that often. And they're miles and miles better than the Cisco SMB switches they replaced.
I'm spoiled by all my Arista gear which you wouldn't know was a switch. Things just happen, immediately.
My 7280R3's are particular monsters but even the 7010's and 720XPs are near instant when running any command.
My 7280R3's are particular monsters but even the 7010's and 720XPs are near instant when running any command.
I don't get how Juniper etc. don't throw a 5 years old Qualcomm ARM chipset on it as control plane and call it a day; they really are stupid slow compared to the worst Android phones on the market years ago.
Aristas - it's okay on CLI immediate mode but if you use sessions a la Junos - so you can send multiple commands in peace, diff and confirm - it's also a half a minute wait. Diff takes forever, it's CPU bound.
I write SDN-ish code for it, at first against vEOS on Hyper-V that responds basically immediately, then you deploy to staging and discover that actual hardware switches are WTF SLOW.
The commit speed depends on both the architecture as well as how many members there are in the VC. We have VCs of EX3300s with varying numbers of members; 2-member stacks only take 20 seconds or so to commit, while the 8-member ones are closer to a minute. Transfer-on-commit happens in the background after the commit completes, so it doesn't have any bearing on commit speed.
Newer Juniper switches did move to better ARM chips (previously were a mix of low-end ARM and PowerPC) and, in the higher-end stuff, Intel CPUs. They commit much faster. Bear in mind a commit isn't just saving a new config to flash; it's compiling an image to write to the FPGAs on the dataplane.
I don't even mind the commit speeds that much, although needing a commit to disable a port and another commit to enable it gets tiresome quite fast; it's the tiny amounts of junk-quality flash that, to add insult to injury, fails quite often, that is my least favorite feature of Juniper hardware.
TIL there's a ridiculous and brand new bug in a place I never expected: In the schtasks command, even if you enclose the path of the executable to run in quotes, it will now split the path along spaces. So if the full path is "c![:\](https://cdn.arstechnica.net/civis/data/assets/smilies/slash-1x.png "Slash :\")
Program Files\task.exe", in the resulting Task Scheduler item, it'll only try to execute cProgram and consider Files\task.exe to be an argument.
FFS Microsoft if you still can't get spaces in paths working correctly, then why the fuck did you name one of the most common folders in the filesystem with one??!!
EDIT: After digging some more, it looks like this is actually a bug that Microsoft fixed? I'm seeing references that you have to double-quote paths with spaces to get schtasks to handle them correctly. This script has worked perfectly for years and just now it's an issue.
Program Files\task.exe", in the resulting Task Scheduler item, it'll only try to execute cProgram and consider Files\task.exe to be an argument.FFS Microsoft if you still can't get spaces in paths working correctly, then why the fuck did you name one of the most common folders in the filesystem with one??!!
EDIT: After digging some more, it looks like this is actually a bug that Microsoft fixed? I'm seeing references that you have to double-quote paths with spaces to get schtasks to handle them correctly. This script has worked perfectly for years and just now it's an issue.
Last edited:
I've run into that. Using single quotes worked for me:
Code:
schtasks /create /f /tn "Test" /tr "'c:\program files\test.bat' arg1 'arg 2 with spaces' arg3" /sc Daily /st 00:00
I would guess mostly because frakking professors are still teaching it as if it were anything but historical context.
And then argue with you when you point out that it makes them look dated and ignorant to keep using terms that haven't existed in 20 years.
Isn't it like 40.years by now?
In general, I find that people use "class C" as shorthand for 192.168.x.x, "class A" for 10.x.x.x, and have no idea that 172.16.0.0/12 is a thing.
I know it's pedantry, but you wouldn't believe how many people argue this with me.
Them: "I need a class..."
Me: "Let me stop you there. What size CIDR do you need?"
Them: "Duh like I said a class..."
Me: "Nope. You can tell me what size of subnet you need, or you can not. Either way, Classful networks don't exist anymore."
Them: "A CLASS C!!"
Me: "Okay, but we've turned off classful routing back in 1992 or so...good luck with that."
If you really want to perplex them, explain (as sryan2k1 was alluding to) that only the first few bits of the address denote the class of the address scope in classful networking. (I cover this in one of the FAQs in this forum)
Them: "I need a class..."
Me: "Let me stop you there. What size CIDR do you need?"
Them: "Duh like I said a class..."
Me: "Nope. You can tell me what size of subnet you need, or you can not. Either way, Classful networks don't exist anymore."
Them: "A CLASS C!!"
Me: "Okay, but we've turned off classful routing back in 1992 or so...good luck with that."
If you really want to perplex them, explain (as sryan2k1 was alluding to) that only the first few bits of the address denote the class of the address scope in classful networking. (I cover this in one of the FAQs in this forum)
We use 169.254.0.0/31 on all directly connected L3 links (direct physical connections between peering routers, or MLAG interfaces).
That confuses far more people than it should.
That confuses far more people than it should.
Today I learned: there is a great Linux app named CPU X if you are looking for CPU-Z (windows app) alternative for those who want know more about hardware specs they use.
I would raise an eyebrow, but I'm an amateur. Aren't link-local IPv4 addresses supposed to be unroutable? And you're giving 169.254.0.0/31 to one link and 169.254.0.2/31 to the next link, right?
As for the /31, novices (like me) get drilled about network addresses, host addresses and broadcast addresses when learning VLSM, and the smaller useful subnet being a /30. Only later we're told about the /31 hack for PtP connections.
Basically, yeah.
There's no routing going on between those interfaces so you can use APIPA addresses without having to burn up routable addresses.
So, they're unroutable (heck, not just unroutable, 0.0/24 and 255.0/24 are reserved and unavailable for auto-configuration, so you'll never clash with anything else) but they can be next-hops on a BGP routing table?
The trick is the packets are neither sourced, nor destined for a link local address. The traffic isn't headed "to" that IP, it's headed through it.
/31's are not a hack, but some vendors took a very, very long time to implement it. You get double the IP utilization when dealing with P2P networks.
Sure, because again, the route is "Connected", not static/dynamically learned.
/31's are not a hack, but some vendors took a very, very long time to implement it. You get double the IP utilization when dealing with P2P networks.
We never use anything but 169.254.0.0/31. This is for iBGP peering between directly connected edge routers fed via divergent ISPs
Last edited:
If you need to pin apps to certain versions and/or only install verified checksums, I don't think you can do it with winget at the moment. The good thing is, since winget isn't really a package manager but more of an installer manager, and installers in Windows are pretty self-contained, you don't need to pin libraries like in *nix to prevent breakage, and the reasons for pinning have more to do with licensing, stability or features.
The software which doesn't give you an easy way to discern logging levels, bonus points that it has a logging level for 5+ different logs, are misery incarnate. I just want to know why suddenly the server is logging 3x what it was before.
Isn't that the IPv4 autoconfiguration address range? Feels like someone just kept using it since Win95? days.
edit: though that'd be a /16.
edit 2: ah ninjad of course and explained.
It's link local, and the autoconfig RFC excludes the bottom and top /24 of the /16. Technically it's "reserved"
Fucking Aspera.
They run SSH over port 30001 which both zScaler and Palo-Alto does not like (as it should!) We had to whitelist a jumpbox to be able to download a bunch of client files.
They run SSH over port 30001 which both zScaler and Palo-Alto does not like (as it should!) We had to whitelist a jumpbox to be able to download a bunch of client files.
Then you have customers with devices / prosumer routers that can't use /31's. Hate burning 4 public IPv4's just so two routers can talk to each other on a /30...
Last I checked, Windows does not support /31 either.
YIL that when troubleshooting installation errors, I should start by checking CPU architecture. These days you never know when a perfectly innocuous Windows laptop might be hiding an ARM CPU inside, and "Setup wizard ended prematurely" is not exactly a helpful error message (thank you FortiClient!).
YIL that when troubleshooting installation errors, I should start by checking CPU architecture. These days you never know when a perfectly innocuous Windows laptop might be hiding an ARM CPU inside, and "Setup wizard ended prematurely" is not exactly a helpful error message (thank you FortiClient!).
If your going to publish a HCL for the new software version, which is currrent, then making sure the link actually works should be a priority.