I've had an article about our .NET Framework 3.5 SP1 issue, where the Records Center went wrong after the .NET Framework 3.5 SP1 installation. Well, that story comes back to my life again and again, so I had to search forward the issues.
Well, Anders mentioned the loopback check in his comment as well as the Microsoft MCS recommended me to check that. (Un?)fortunately I’m too curious and the simple solution is not enough to me. I wanted to know: why?
First of all, some facts:
- My post about this issue was written on October 31, 2008.
- Another post about loopback check was published on Ocober 30, 2008 here. It isn’t about the Records Center, but contains a good description and something very important to us (highlighted by me):
“The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server.”
- The current .NET Framework SP1 was published on November 18, 2008:
All in all, setting off the loopback check can help us if the requests are local on the server. Sounds good, but the Records Center was tested from remote computers as well, not only from the MOSS application server! In this case, only one thing can be the root of every trouble: if there are some local requests during the Records Center operation. Let’s see, what happens!
First of all, about the Records Center in a nutshell. The Records Center is based on a special site template, and practical to create it at least into a separated site collection, but very often into a separated web application. Moreover, we have the chance to use a Records Center from a remote SharePoint farm.
After creating the Records Center, we have to configure a few things (for example records routings) and set in the Central Administration site which Records Center we want to use. This setting is based on the web service of Records Center located at /_vti_bin/officialfile.asmx.
Well, on the face of it, if we send a document to the Records Center, this web service is calling:
But if we see behind the scenes, we have to recognize that after clicking on “Send To –> My Records Center” there is a calling to the local server’s SendToOfficialFile.aspx located in the LAYOUTS folder. After that, there are the following requests in the background:
That’s it – after calling the SendToOfficialFile.aspx there are a lot of API callings, and the officialfile.asmx is only at the end of this queue! Moreover, if the Records Center is on the same MOSS server (farm), this calling is local! Yes, this is the root problem, our loopback check problem just became understandable now!
Of course, this is a solution to our question, why the Records Center wasn’t working even if we’ve created a new one to the same server.
One more thing. Unfortunately the error messages are not too obvious in this case. For example, the error message got here (”The DevRC Records Center could not be found or accessed.”) can be occured by other errors as well. This is because behind the Records Center’s operating there are not too much error codes, as we can see in this enum:
I hope that’s the real root of the issue and can be resolved first, last and all the time, and I don’t have to say: “to be continued”