If you’ve worked with MOSS long enough, I’m sure you’ve seen this error. The reasons that it occurs are numerous, and may even be blamed on poor error handling / reporting by the programmers.
If you’ve come across this error, and turned <customErrors /> off in your MOSS site’s web.config and it still occurs, you may have run into the issue that I did.
This can occur right after MOSS installation, or on a farm that has been up and running for some time, and this is something quick that you can check to make sure it’s not the reason, especially if your server is managed through AD or an admin that is really tight on server security.
My instance of this error was on a completely locked down Windows Server 2008 installation. The cause was one setting that was applied through Active Directory (AD) Group Policy Objects (GPO), Use FIPS compliant algorithms for encryption, hashing, and signing.
To check this:
Start > Run, and at the run prompt, type: rsop.msc
(rsop.msc = Resultant Set of Policy snap-in)
You may be challenged by UAC (User Access Control) if you have it enabled (Vista and Server 2008).
Navigate the tree that appears as follows:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
Scrolling down in the right side of the window, view “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”. This setting should either be “Not defined” or “Disabled” in this window.
If you don’t know, the Resultant Set of Policy is a combination of all policy settings that are being applied through AD GPO’s and Local Security settings.
If this is your problem, i.e. the setting is enabled, you can check your local settings by running SecPol.msc. When this snap-in opens, navigate through:
Security Settings > Local Policies > Security Options
… and again look for “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”. If it says enabled here, right-click it, choose properties and set it to ‘Disabled’.
Refresh your RSoP window and again view the policy. If it’s disabled, now you’re all set, otherwise contact your AD administrator and ask them to change the policy.
Hope this helps someone out. Add it to your bag of tricks for troubleshooting vague MOSS errors.
Again, this scenario is likely to be encountered on servers that have security templates applied.