The PKI is based on CA certificates, which are certificates you trust to vouch for other certificates.
You will always have a copy the certificate for the CA. Let's call it "bdxCA"
When Bob comes with a certificate saying "Hi, I'm Bob, here's my certificate signed by bdxCA", the computer looks up his copy of bdxCA, see it did sign the certificate and that it trusts bdxCA for the stated purpose (e.g. user identity).
Now come Intermediate CAs. These are certificates that are able to sign other certificates but you are not trusting directly, but whose trust derives from a "real" CA.
So, you may have bdxCA signing bdx_HR_CA which itself signs Bob certificate. Here Bob should provide both his own certificate as the intermediate one(s): "Hi, I'm Bob, here's my certificate signed by bdx_HR_CA, and you can see that one is signed by bdxCA". You check that it is indeed the case, and accept it.
If Bob hadn't provided the intermediate certificate, it might or might not be accepted. If the receiving side don't have a copy of bdx_HR_CA, they won't be able to validate it, and will thus reject it. However, it is possible that the intermediate CA was imported locally (so it will be able to find it), or perhaps Alice had already shown her own certificate as well as bdx_HR_CA one, and thus the later had been automatically stored. Moreover, in some cases certificates include a url from which the parent (intermediate) certificate can be downloaded, and certain clients are able to helpfully download them.
All of this leads to the case that when intermediate certificates are missing, they may or may not validate, depending on the software used, and the previous machine history, all of which results in inconsistent problems, as they only sometimes fail.
Then, it is also possible for a CA certificate to also be signed by another CA. This is generally done when a new CA may not be trusted by all clients. Signing the CA by another one that they do trust allows them to trust certificates emitted by this new CA (by treating it as an intermediate one).
In your case, you have imported the CA certificate, but you probably haven't marked it as trusted, so Windows doesn't have a route to a trusted CA to verify it.
Finally, as your use case is about at VPN server and VPN user certificates, please note that these generally use their own CA, with the server CA provided within the VPN configuration. In which case, it doesn't matter if it's trusted by windows or not, as the VPN client will simply check if the VPN certificate is the one it is expecting it to be.