AbydosOne

I tried to set it up not that long ago and you can't on consumer Windows. You can use a RAID5 array made in Server in Home/Pro, but you can't make a RAID5 in Home/Pro. (Unless you know a way I don't, because I couldn't through Disk Management.)

I can't speak to Storage Spaces, but the standard Disk Management RAID-5 is only available on Server builds of Windows.

Are you sure they're SATA and not SAS or NMVe/U.2?

Let's back up... why do you want it to not check?

TBH, this is a pretty standard rate of emailing for a marketing push, especially when you're trying to "convert" someone who already showed interest. These aren't unsolicited if you started making an account, and they're reminding you to finish it. If you have a problem with those emails, use the unsubscribe link in the email.

I went through three different Windows tablets over a 5-6 year span before I gave up on the concept and bought a convertible laptop. Dell Venue 8 Pro ($200-ish): Win8 on 2GB of RAM was horrible. Screen got really discolored for some reason. Microsoft Surface Pro 2 ($500-ish used): the battery management died so it always reported a full battery. Asus Transformer T102HA ($300-ish): the CMOS battery died, so the clock wouldn't stay synchronized when it went to "sleep".

You can only expand to the "right" in your drive. You'll need to use a disk partitioning software (with a preboot environment) in order to move your Windows install partitions over to the "left" into the unallocated space so you can expand to the "right".

I've used my XM4s on Zoom calls on my laptop without issues... you should be able to change the audio and microphone inputs away from the "headset" settings to the other options.

Use \\[IP address]\Share Drive\ instead of \\TV-PC\Share Drive\. Sometimes the local domain names don't get registered properly with your gateway, so IPs are the foolproof method.

Well, I'll be... IT got back to me... They actually just dictionary/brute-forced it. That's actually kinda neat.

This is different scenario than we're discussing. If a bad actor had direct access to the server, we can surmise that encryption keys are either known or bypassed. If I send encrypted plaintext of my password, bad actor now knows my plaintext password. If I send encrypted hash of my password, bad actor knows my hash, but not the text. Either way, they can (in theory) use that password/hash to authenticate my account on this particular authentication system. The utility of knowing a password is to try it on different authentication systems. Assuming competent authentication design, the hashes will be salted to a particular application and submitting them to a different one will not result in a valid authentication (not saying there aren't incompetent ones out there). My presumption is that AD servers store that password as a salted hash, and only ever receive a salted hash from the client via encrypted (TLS/SSL) channel (which seems logical, right?). So how does IT (functionally existing at the "direct access to server" point) know enough about the contents of my password for it to not pass audit if the plaintext is never sent to the AD server and (presumably) they didn't spend the time to brute-force unhash everyone's passwords?

Encryption keys can be stolen; hash functions need to be brute-forced (there are some optimizations, which is why salting exists, but there's no universal reverse function by definition).

Hash algorithms are deterministic? If I hash my password or the AD server hashes my password, it's still the same hash... so why send encrypted-but-plaintext password when you could send encrypted-and-hashed password? Why have a remote cleartext step at all? All the server needs to do is compare the hashes, it doesn't need to know the original password string, right? Seems like a massive security hole to have cleartext passwords in RAM outside the client PC.

My understanding of password validation is that they compare the "encrypted"/hashed values. Passwords shouldn't ever be "decrypted", I'm pretty sure, especially if the "encryption" is a hash algorithm that is computationally very expensive to reverse.

Nothing that runs before login, that I'm aware of. Obviously they have third-party permissions management, but I don't think it's low-level enough to get into the login process. Well that's not sketchy at all... maybe I should stop writing posts from my work computer lol

Yeah, this was the part that stands out. I haven't changed it since last June, and it didn't flag it then, so somehow they're accessing it in plaintext after the fact. I emailed them back, just to see if someone would reach out to me about it (I doubt they will).

Lately, my corporate IT has taken it upon itself to "audit" our passwords and declare any as "being vulnerable to modern hacking techniques" (i.e. contain personally relevant strings, like, say, address number) needing to be changed. I know exactly why my password doesn't pass muster (though work is the only place I use it, so IMO it's not that vulnerable, I'm just stubborn and our IT is notoriously not-competent), I'm just a little incensed that somehow IT can view passwords in plaintext!? Does Active Directory not store hashed passwords? Is there a hashing algorithm that can extract substrings for comparison? 1 Or is IT really so hypocritical as to actually store/unencrypt passwords in plaintext somewhere and then tell *us* to be more secure? 1 = The only way I could think this would be possible would be that the "hash" of the password would actually be a collection of hashes of various substrings when it's made, but I can't find an evidence that this is true.

Hire an electrician before you hurt someone. There's no shame in admitting you don't know, and a bruised ego is better than a smoldering pile of ash.

Sounds like there's a short in the laptop and the brick is shutting down to prevent damage.