It is theoretically possible to migrate to the "two tier" approach without having to re-issue the certificates, but whether this is a good idea is not clear.
When some system verifies a certificate, it builds a chain leading from a trust anchor (a "root certificate" which is hardcoded in that system) to the certificate which is to validate (called "EE" as "end-entity"). The basic idea is that each certificate in the chain contains a public key which is used to verify the signature of the next certificate. The root certificate is also signed because the certificate format includes a field for a signature and that field is not optional; however, nobody verifies that signature (the trust anchor is trusted "by definition", not because it is signed) and it is traditional for a root certificate to be self-signed.
The verifier will accept the chain if the signatures are cryptographically correct, and also if the certificate fulfill a horde of properties which are detailed in X.509. To make things simple, each certificate has a subject name and an issuer name; the issuer name should be equal to the subject name of the certificate which issued it (i.e. the previous certificate in the chain). There again, the root certificate has no issuer, so it is traditional (but not required) that the root has itself as issuer (its issuer and subject names are equal).
So you want to replace the root by the combination of a new root, and an intermediate CA issued by the new root. If the intermediate CA certificate contains the same subject name and the same public key than the old root (and the same "key identifier" and other X.509 extensions), then the previously issued EE certificates will be verifiable against both the old root (as they do presently) and against the new root, as part of a chain which begins with the new root, goes through the intermediate CA, and ends on the EE.
I have no idea whether Microsoft Enterprise Root CA will offer a convenient interface for creating that intermediate CA which reuses the characteristics (name, public key...) from the old root. But if it does, then creating such an intermediate CA will do half of the work of the migration, without requiring immediate replacement of existing VPN certificates.
You are still not done, though. The new root must be deployed, i.e. verifiers must be made aware of the new root, and should also forget about the old root (the latter can be slightly delayed). This is the expensive part and it is tricky because the trust anchor is, well, the foundation of your trust system. You do not want to "educate" your users into fiddling with the trust anchors just because an administrative-looking email told them to do so.
Now there is a structural technicality which must be well understood. In a VPN with client certificates, the verifier for the client certificates is the server. However, such VPN probably also uses server certificates, which are verified by the client software. When you change the root CA used to verify client certificates, then the new root must be inserted in the system which does that verification, and that's the server (so, presumably, this is easy). You need to change the trust anchors in clients only when you switch to a new root certificate in the PKI which issues server certificates. Possibly, you used the same root for both sides, but this is not an absolute requirement.
The main reason why you would want to have an intermediate CA is for damage containment. The intermediate CA is the one which signs new certificates, on a daily basis. Thus, it is probably online, possibly duplicated, and thus vulnerable to attacks. If it gets compromised, you can then power the root to create a new intermediate CA (with a new key) and revoke the previous intermediate CA. Thus, you can recover from a compromise without having to change the trust settings in verifiers. You must still issue new certificates to replace the certificates which had been issued by the now-compromised CA.'
In your VPN system, I assume that there is a single server, or maybe a select few servers, which you directly control. Changing the trust anchor in that (these) server(s) ought to be easy and cheap. Similarly, issuing new certificates for the servers is easy. And you do not do that often, so the root for the server certificates can be offline and does not need to scale: it will be executed once or twice per year, no more. There is little need to have a two-tier approach for the server certificates since the intermediate CA can be managed in the same way than what you would do with a root: offline, down most of the time, kept in a safe. As for the client certificates, you issue many certificates, so the CA for those must be up and networked and scalable and thus vulnerable; but if it gets compromised, then changing the trust anchor for the client certificates is not hard: that trust anchor is in the single VPN server. So while you can have a two-tier approach there, that extra level will not buy you much: it will only save the cost of changing the trust anchor in a dozen servers, i.e. a ten-minute job for a sysadmin, at most. The real cost for a compromise of the CA which issued client certificates is that new client certificates must be issued, immediately, and having a two-tier CA changes nothing to it.
"Two tier" PKI with intermediate CA certificates is a good idea when there are systems where both the certificate owner and the verifier are out of easy control by whoever manages the PKI. In a VPN / RDP setup, this applies if you have hundreds of servers, making the cost of changing either the server certificates, or the trust anchors used by the servers, non negligible.
Now I have been overly verbose. To sum up:
- Transforming a root CA into an intermediate CA without impacting the previously issued certificates is theoretically possible.
- Whether a given PKI system implementation offers an easy-to-use interface for that is another question.
- A "two tier" is a good idea in some situations, but for others (including what I assume about a typical VPN installation) it does not buy you much, and since it adds some complexity, it is unclear whether it is worth the effort.
- To think about a PKI, you have to identify who verifies which certificates. In particular, the server PKI (the PKI which issues certificates for servers, which are verified by clients) and the client PKI (the PKI which issues certificates for clients, which are verified by servers) need not be the same and probably call for distinct management processes.
