During the process of adding a Gateway server for an Operations Manager environment, I received the following error while adding a certificate using MomCertImport.exe.
The certificate is valid, but importing it to certificate store failed.
Error description: Catastrophic failure
Error code:0000FFFF
Now to me, a catastrophic failure makes me think the server is going to burst into flames. While I doubt that will happen, I think someone had a good sense of humor when they wrote that message.
Some quick research didn't help me resolve why I got his error, other than asking whether the other users having this issue had stepped through some magical documentation, as if it would inspire some fairy dusted insight and everything would just click. While documents with instructions are great, they don't help allot if you don't understand what you are clicking on and what to do if your prompts or environment isn't as described in the document.
This is not to say that the following two resources are not useful, as they are quite so. I would recommend both of these resources, although it is also good to understand PKI and certificate management before blindly following instructions on setting up your environment. I mean, how do you know that what some document on the web is telling you isn't going to open you up to vulnerabilities or just malicious.
For securing your OpsMgr environment refer to System Center Operations Manager 2007 Unleashed, Chapter 11 Obtaining a Certificate. It has great step by step instructions, although I did find some missing steps. Additionally, this web doc was a good resource and built upon the knowledge from the above book, although it had more step by step instruction that if you were not already familiar with the processes could require just blind faith in implementing. Great for a lab but not for blindly building your production environment. http://www.systemcenterforum.org/ops-mgr-2007-gateway-server-and-pki-scenarios-document/
Anyway's, I easily resolved the issue and had a couple words of wisdom from my trials. Note, all of the following information assumes that you have read the documents from above. Using MomCertImport, there are two options available in the tool.
The first (given in both the examples above) uses the exported PFX certificate file. This is used by opening a cmd shell and executing: "MomCertImport <path to PFX Cert file>" with the optional "/Password <password>" added to the end. If you don't specify the "/Password" parameter, the tool will just prompt you for it. Mind you, if you export the Cert without specifying a password, you will not be able to import it because the utility will not take NULL passwords.
The second option is to use the "/SubjectName" parameter for the tool. This allows you to use the installed cert without exporting it to a file and possibly opening your cert to being compromised if you have a simple password (I bet half of you use some variation of "password" when exporting) and the file falls into the wrong hands. The command would be like "MomCertImport /SubjectName <subjectname>". The subject name comes from cert if you view the details of it from the MMC. (Note that you gave the subject name when creating your request for your cert, it was the FQDN name of the server).
Now come the problem of why the catastrophic failure occurred and why everyone says to refer to the documentation. When executing MomCertImport using the file, the cert will be opened and then will be validated against the root authority, while using the subject name option will assume the certificate is validly installed and will just use its information. Either option will then pull the serial number from the cert and put it in the registry for the OpsMgr Health Service to use. While this works fine on domain resources that request certs from enterprise CAs, if you cert was requested from a server or client that is not part of the PKI infrastructure, then the cert you get and install will not be able to be validated against the root authority. This is because the Root CA that you requested the cert from does not also have a certificate in your trusted roots store.
You can validate this by observing the first page of the details of you certificate. If it says that it installed but is not valid, then you may want to refer to the web document above about "Retrieving and installing the Root CA certificate". Now the workaround to the catastrophic failure was to use the SubjectName parameter, but you can then imagine what my next problem was. I spent a bit of time troubleshooting supposed communication/firewall errors because even after using the tool and seeing the cert serial number in the registry, I was not able to get the gateway server to talk to the management server. After authorizing the gateway server on the management server (the one that had a external FQDN with a hole for port 5723 into the internal network) I was seeing error in the eventlog talking about opening the communication to the management server but that the management server closed it.
Obviously this was a cert issue. Just as I was going to blow all the certs away and start the process back from the beginning, I saw the cert error in the MMC and it all came to light so quickly. Right after adding the Root Authority cert, everything worked. Now this could have been resolved quickly if I had just paid attention to the instructions (although the book didn't refer to this) or if the error message on the utility would have been better.
So to wrap it up... First, my servers did not catch on fire, so the "Catastrophic Failure" was way overstated (although it did cause some pain). Second, making sure that you have valid root authorities for your installed certificates is important (whether they are yours or from the external CA that issued your cert). Third, don't just blindly follow documents or instructions without understanding why you are filling specific fields or using specific names. I see this many time when assisting others in troubleshooting certificates on webservers and ConfigMgr.
Actually, I can't believe I didn't catch my cert error in the first place. I hope this helps you save some time, whether it is for OpsMgr or for something else.
Not. While useful for developers, trace logs and debugging should not be accessible to external visitors. Not only does it allow the user to peak inside your directorystucture, code snippets, and possibly even values, running code with debugging assemblies or flags enabled adds overhead to your servers.
I have been an advocate of branding systems so that automation scripts and reporting can be executed to get the information branded. While SMS and ConfigMgr clients can read information from a system and dump it to a database, it is only as good as the information gathered and generally cannot be referenced when executing installs or non-SMS functions. In addition, sys admins have come up with some pretty ingenious ways to make changes to reports or editing the def.mof to manipulate the data to get results they want from a database they didn't design.
This brings me back to working on Enterprise Branding scripts. The way I see it, if I can collect some information that is frequently changing, evaluate whether the change is warranted, and place the information on the system local to the change, then I can use that information in many different ways later. If you are scratching your head and wondering what I mean, let me give you an example.
What if you need to identify who is the owner of a computer in an environment where users share PCs, so that you can push software out to the user. In today's world, you would rely on ConfigMgr queries for last logged on user or AI reports or worse yet, just push to the user and forget about licensing issues. These solutions can be spotty and do not take into account real-world use of systems, let alone pushing software to a user who logs into a lot of systems or even servers. Well, I say who better to know the common user of a PC than the user themselves.
By running an application/script at logon, based on information gathered from previous logons, I can evaluate whether the user is a first time logon or frequent logon. Based on that information, I can then decide whether to prompt the user to become the "computer owner" and save the results into a local place on the system (In this case, a registry key). I can then use that information during install processes, management scripts, and even having ConfigMgr gather the information for queries and reporting later.
Enterprise Branding is a way of gathering only specific information that you would want to evaluate and use, whether through SMS or other means, and placing it into a common location for your use later. This could be a registry location, WMI, Environment Variables, or even static files (IDMIF, NOIDMIF, or your own custom log). The key is identifying the information that is most valuable to you, deciding how you would most likely use it, and then based on that, a place to save it.
For example, if you were going to use the information in logon scripts, then an environment variable might be the easiest way to use the information. If you want to use it in ConfigMgr, than maybe putting it in WMI or the registry would work best. The cool thing is that you can then build automation around the expected information and use it to your advantage. Some examples:
- identifying the main user for user state migration before rebuilding a computer
- identifying the common user to make specific registry changes to their profile
- recording asset information for system update scripts or quick reporting
- identifying the main user of a computer to target deployments to (logic in the install would evaluate whether the current user getting the deployment was that main user of the computer)
- identifying the department or physical location of a computer to target deployments to it.
Here is an example script I was working on that would be shown when the system was first deployed to a user. Logic in the script would identify if information had changed and then display the form to the user to make changes. This information was written to the registry and then was imported to SMS through customizing the def.mof or IDMIF files.
The whole reason I bring this up is because I was in the forums and came across an issue someone was having and they were working quite hard on making mof changes to read a registry key for information. I had mentioned that I had previously worked on Enterprise Branding scripts and there seemed to be an interest. One of the benefits of starting this project back up is that a common tool would create some common registry paths that could make a simple mof change for use in SMS or ConfigMgr. If there seems to be an interest, let me know and I will start this back up.