Hi, I've been getting to grips with the operations of a 2 tier PKI (Offline Root and Online Issuing/Policy CA's) and from my previous installation of AD CS which I've uninstalled, there's data in the Configuration Naming Context within AD still. There's currently entries relating to the original - uninstalled - PKI in:- CN=AIA,CN=Public Key Services,CN=Services,DC=Domain,DC=local CN=CDP,CN=Public Key Services,CN=Services,DC=Domain,DC=local CN=Certificate Templates,CN=Public Key Services,CN=Services,DC=Domain,DC=local CN=Certification Authorities,CN=Public Key Services,CN=Services,DC=Domain,DC=local CN=KRA,CN=Public Key Services,CN=Services,DC=Domain,DC=local CN=OID,CN=Public Key Services,CN=Services,DC=Domain,DC=local In my new test domain (yes I should have done this all in test first - but I've now got test servers which I've running the new processes on) there's zero entries in these locations so would I be safe in saying I can go hacking these old entries out of AD before I install the new AD CS implementation? FYI, There is NOTHING in the operational domain that's relying on PKI, there was no auto enrollment done or anything like that. I just want AD to look and feel like it would if I got it all right the first time round and this was my first installation using AD CS, even though as I've already described, it isn't. Regards Paul.

go into Enterprise PKI (MMC snap-in installed with AD CS or inluded in the Remote Server Administration tools for AD CS) and rightclick on the root node - select Manage AD Containers and delete everything what is there related to the removed CA. ondrej.

Hi Ondrej, Because AD CS isn't installed, those tools aren't available to me at the moment. I had previously done exactly that using the Manage AD containers tool and this information is still persisting in the directory. Any more thoughts? Regards Paul.

don't understand you. just install Remote Server Administration tools for AD CS or Resource Kit 2003 and purge the things out. o.

Well, seeing as my AD has no PKI whatsoever in it, what is my AD CS Administrative tool going to attach to? Any attempts to run the Certification Authority Snap-in using RSAT from a workstation result in "The specified service does not exist as an installed service" because there are no CA's available to direct it to Remote Server Administrate, as the tool suggests. Again, returning to my original reply, I'd already done exactly as you'd suggested by using the Manage AD Containers tool, so I'm there with your suggestion, I've removed the AD CS roles from the two Issuing CA machines which were Domain Members and I still have data that persists in the aforementioned AD Naming Context. My question is, are there any ramifications to taking this seemingly redundant data out manually using ADSIEdit given I want a clean start in an AD environment which has already, briefly, had a PKI exist in it for a short period, but with no infrastructure relying on it. OR, am I being seriously over analytic and it's actually just fine just to install the PKI hierarchy again as it'll over-write any data using the same naming structure when it's going through the installation process and adding Certificates to the DSStore? Regards Paul.

no, not the CA snap-in. Start MMC.exe, Add snap-in Enterprise PKI. If there is a supported tool it is always better than deleting directly from ADSIEdit. o.

Unless I'm really missing something, I really don't believe that Enterprise PKI is available as a snap-in unless you are running a machine with AD CS installed, either as a Standalone or Enterprise CA. So yes, there is a supported tool, I already used it as you suggested when I was decomissioning the old erroneous PKI and I don't believe I'm able to re-use it until I've installed another PKI at which point I've missed the point of cleaning up AD before installing the new PKI. I understand that it's better to use the tool rather than go hacking manually, but again, unless I'm missing something, I don't have that option. The conversation's not really about the ability to run the Enterprise PKI tool anyhow, it's about knowing whether or not this data can be removed, and if it is simply the data that the tool removes, I would assume so, would you not? Thanks for your replies Regards Paul.

yes, the data from inside the containers can really be safely removed according my own practice :-) except for the OID key, which is populated with OIDs and their descriptions and the Certificate Templates which could have been customized. AIA and CDP containers contain only the distribution points for the CA certificates and the CRL lists if distributed over LDAP - in this case removing the old CA makes these unnecessary as well as invalid. Certificate Authorities is a container that contain CA certificates which should be installed into Trusted Root Certiifcation Authorities on computers appying autoenrollment. If there are other CA certificates than the one of your former CA, then I would leave these there because somebody must have installed them there manually to make them trusted on clients. KRA is just list of Key Recovery Agent certificates published so that the CAs can use them (when configured) to archive private keys. This is again only a publishing place which could be repaired if unwillingly deleted. So no harm. ondrje.

Thanks Ondrej, Regarding the OID, nothing anywhere actually ended up using the PKI that was initially installed, I was under full control and am fully aware of the distribution, or lack thereof of certificates throughout the enterprise, so would I be safe in getting rif of the OID data too in your opinion? Regards Paul.

be careful, I don't know. May be you can always export it first and in the case of errors import it back again. But as I think, this is not a good idea. You will not gain anything by deleting them. OIDs are universewide unique (unless some extraterestrials are using them as well :-) and there shouldn't be any collisions especially in your "clear" environment. ondrej.

You are missing something<G> Just add the ADCS role management tools from Features. Then you have PKIView.msc without the ADCS role being installed. As Ondrej had mentioned, do not delete from ADSIEdit.msc... Too much chance for things to go wrong. Brian

Do not delete all of the OIDs from the OID container. Just delete the specific OIDs for Application Policies or Certificate Policies that you have created. You can use ADSIEdit.msc to verify the custom OIDs by vieiwing their CN attribute. Brian

Brian, Magic, thanks so much for pointing that out, yes I now have PKIView available and can now see the AD Containers as Ondrej and I were at pains to reach earlier in the thread. I've also associated (in my head at least) where the OID's are coming from in relation to the PKI MMC tools, and yes, it would be un-cool to delete that lot, there are no custom ones there, but I now appreciate that they don't need to go anywhere for me to achieve my goal of a clean start after my initial ____-up of an installation. It's a real learning curve to get a fully fledged PKI up and running. If you're needing a quick-fix PKI to use for some boxes and network devices, I can see it's very quick, as per some peoples fast track walkthroughs on the web, but actually being able to grasp the operations and being able to do knowledge transfer with colleagues with some sort of authority for an Auto-Enrollment, OCSP, NDES, fully deployed PKI is a distinct difference to a knock it up for IT only PKI. The main thing that's helping me is running a couple of servers, (offline root and Ent Edition 2008R2 CA/DC + Win7 client) test boxes with 4 day RootCA expirations and similarly short sub ca and issued certs to see the lifecycle happen in front of my eyes and see all the operational functions happen, go wrong, fix etc etc. I highly recommend anyone designing and deploying like me to do the same if you are new to this all. Ondrej, Brian, Thanks for your excellent and fast responses, I dare say I'll be back with some more questions soon! :) Regards Paul.