Domino

The CRL and OCSP URLs need to be available *as listed in the Certificates* The checks will look for the URLs as they are on the certs, so that's what needs to be available.

External publishing is only required if you need to validate the certs from outside.For example, if you were going to use internal certs for VPN connectivity, the CRL would need to be externally accessible. And yes, you could install the trusted certs on a third party device if they're in that directory. If what you're publishing it through supports limiting browsing to specific URLs you could only allow the needed paths though. Regardless that isn't the end of the world - it means the external machine would trust certificates from your CA, it doesn't give it rights to request a cert or anything.

I assume I did something terrible in a past life.

Nice, seems like you're almost there. You'll want to either move your CRL point to the subordinate CA, or add it as an additional. That way it can be used as a check for anything internal - https://www.vkernel.ro/blog/how-to-publish-the-crl-and-aia-on-a-separate-web-server When all that is working, you should be able to get domain members auto renewing machine certs. This'll let you do things like this, but also have certificate based VPN authentication or similar down the line (that'll require externally accessible CDP/CRL though). And even have user certs auto created and added to AD if you wanted to have the option for PGP encryption without the users having to request certs. Having a working CA internally makes a lot of things easier down the line, once you get over the setup.

IIRC you used to need to ensure the target printer was set to "list in directory" in it's sharing settings. If there's an error on setup it should be in the target machine's application event log as "group policy printers" source

Okay, so if the subordinate's cert that has expired is it's signing cert that will need to be resolved first. If you open a cert that was previously signed by this, go to certificate chain and view the certificate from the subordinate - you should be able to see if it matches. If it is that one,you'll need to bring the root CA online, have it issue a new Singing Cert to the Subordinate, and then have that issued to the clients "Intermediate Certification Authorities" store. I'd also ensure you've a GPO with auto-enrollment set up once this is sorted - I believe it's present in the Default Domain Policy on Domain creation, but worth checking

When you request it from the cert mmc with "Computer account" the permissions need to be in place for the AD machine account rather than the logged in user. You could then either make the template available to the machine account and request it through the certificate MMC, or create a CSR and then sign it through the web service. Also to check - the CA and issuing subordinate are both trusted? Their signing certs are both valid (they're usually long validity periods)

If you open up an issued certificate (or issue a new one) and go to the "certification path" tab you should be able to then open up the issuing and root CA certs. If those are valid and in date, you should just need to get the template set up correctly and issue the certificates you need. Is that what you're asking? The question was a bit vague...

Another possible culprit is any SSL Decryption or deep packet inspection that's happening in line. If the appliance doing it isn't able to keep up with the quantity of traffic then you interrupt the real time nature of the call. obviously this assumes the traffic is encrypted, but we have previously seen it happen.

Well, I put it to you that I'm not and you know it!

They've said it so much they've gone horse

It's science reporting in a newspaper - so your base expectation should be that it's 100% incorrect

From my experience VMware can reach a greater VM Density (one of my clusters in London has 398 guests across 9 hosts) due to the way it deals with RAM allocation, and the Failover/HA/FT features just aren't quite there with Hyper-V. Granted it's been a while since I've used it, but I remember the CSV setup being a pain. At the time it also had issues properly assigning multipathing across our HP Flex networking with Virtual Connect. It wasn't a great experience in all, and VMware being *very* good at what it does means the company is happy to pay for it. Also at this point we've a lot of institutional knowledge in the platform, especially around performance tuning. That's not to be disregarded.

Windows Server Roles aren't suitable for containerization...and you'll need to replace it when the OS is out of support. Member servers rather than DCs will save you pain later - if you want to do it *properly* you'd also have an offline CA with online subordinate signing server. This vastly reduces the pain of redeployment if Root Keys are ever compromised.

We block encrypted ZIPs - as they're unscannable by the AV filters. We've ended up adding exceptions for expected transfers. As we're sending the vast majority of our mail over TLS these days it seems unnecessary anyway

I'm only talking site failures in the above. When Three of your Four Exchange servers are up you should have no issues with failover.

Ideally the FSW would be in a third site. That way it's available in a site failure situation to provide Quorum for either Site. If that's not possible, you'd be looking at one site that was able to activate if the other went down, and one which would require manual activation if the site with the FSW went down.

You'd either want an extra server in each site, and extend the opposing sites DAG to it, or to go down to one DAG and have all the mailbox DBs in a single one across all servers. Neither of these will give you full automatic failover without having the FSW in a third site. Attached is my setup, each region is setup like that.

So, what you have here would survive a server failure, but not a site failure. Normally, including FSW, you'd weant an odd number of votes in a DAG group. So when a member is missing more than half the total votes remain, meaning a cluster election can be won. More here: https://practical365.com/exchange-server/exchange-2016-database-availability-groups/ However it occurs to me I thought you could only have 1 FSW per DAG (not counting the alternate FSW setting, which doesn't work like you'd think). So do you actually have 2 DAGs here, with one exchange server in each?

Well, there's a lot to consider here. Which exchange version? How is the namespacing setup between the servers? When you say "a fileshare witness on that site" is that a single or two FSW? Either way achieving quorum with that could be a manual process. Ideally, a two member DAG would have a FSW at a tertiary site. That way a single site failure could be survivable (as 2 votes are available for DB activation out of 3 total).

There's some stills about now, it's not looking great IMO https://www.themarysue.com/fandom-concerned-by-discworld-series-the-watch/

https://community.spiceworks.com/scripts/show/3724-copy-gpo-links-2-0

Same as a RADIUS plugin? It's running over SSL anyway, the VPN only means all other traffic from the target machine will travel to your network (unless you're split tunneling, which has it's own issues) RDP over SSL means the connection is protected whilst also leaving the rest of the machine's connectivity unaffected. On that note - if we're discussing DMZ segregating the target machines, but they're expecting access to internal file shares, resources etc. Surely that will require a lot of holes being poked through to the internal network. At what point is the protection diminished? I feel VPNs should be limited to trusted machines - there's better publishing options for other services

That provides more auth options than a Username/PW how?

If you've got Azure AD Premium P1 or P2, you can use Azure MFA with a RADIUS plugin