My problem is the result of a migration/upgrade gone wrong. In short, I hastened through the migration/upgrade (didn't completely digest the TechNet spec) and inadvertently made a few blunders.
The migration/upgrade was: DC0>CA (WS’03R2 Standard) to DS0>CA (WS’08R2 Enterprise). That is, a root CA; hosted by a domain controller not being an enterprise edition, to a newer root CA; hosted by a member server being an enterprise edition. Note: the CA host name changes for the migration.
The following are the blunders:
- I neglected (overlooked the need) to export a copy of the source CA’s registry settings before I removed it. I realized such during the target CA install so I removed the target CA and went back and reinstalled/restored the source CA.
- During the above source CA reinstall, I read the wrong (proprietary) install spec and thus wrongly named the source CA (as per our 2000 circa;i.e.RootECA). In discovering this, I removed the reinstall and then reinstalled all over again using the correct (current) CA Name (Enterprise Root); this install seemed to be ok. I then exported the needed CA registry configuration.
- Finally, I (again) installed the target CA as per our proprietary spec and (then) diligently did post install tasks in accord with TechNet.
- Now, I found clients to be confronted with “Unavailable” during local AutoEnrollement. In pursuing this, I went to renew the CA (root certificate) hoping to bring forth all CDP updates. In doing so, I now find that the CA renew fails with “cannot create file, Win32: 67”.
In concluding, I’m getting tired …
I did look over the work I did do and can’t find the problem.
So: should I abandon this effort, decommission the current CA, and start all over. Or, should I continue to try and repair?
If an expert deems a repair most efficient; how? If such expert deems decommission as most efficient; what TechNet spec should i start with?
Glenn of xSyLent