Last week the road was rockier than ever in order to get MOSS 2007 properly deployed in a relatively strict security environment. We experienced 4 funny, though show stopping issues, that were hopefully relatively easy to solve!
.Net Framework 3.5 Installation report error message “The application has requested the Runtime to terminate it in an unusual way”
This is an ‘”old” issue caused by the fact that in a security-hardened environment, the Print spooler service might be set to disabled while the .Net Framework setup needs it in order to install the XPS print driver… Yeah, dependencies show up where you don’t really expect them ;).
Take a look at these resources which are really helpful though a little outdated:
MOSS Search Administration Page fails with error “Authentication failed because the remote party has closed the transport stream”
I already met this error under different circumstances: it usually means that the remote web server you’re trying to access requires SSL communications but the server certificate it uses is corrupt or invalid.
My first reaction was: but we don’t use SSL for our Central Admin or SSP so why would it require it then?
Simply because the Search Administration console uses it to communicate with Web Services hosted on each SharePoint server in the farm and in this case, with the query servers in particular.
After some investigations, the excellent tool SSL Diag reported that the server certificate was corrupted on nearly all servers in our farm… How could this happen?
Apparently, this is the consequence on combining the following elements:
- The server that is running Office SharePoint Server 2007 has the query role in a server farm
- The server farm was updated with Microsoft .NET Framework 3.5 Service Pack 1 (SP1)
- The roles of the query server and the index server are not on the same server in the server farm.
And the issue as well as its solution are documented at MS Support under the KB article 962928: http://support.microsoft.com/kb/962928.
Note: although MS says it only affects the Query servers, the server certificate was corrupt on all servers except the Index… So we decided to fix it everywhere for optimal farm sanity.
MOSS Search Administration is unable to retrieve the status of index propagation on Query Servers
The real issue is that actually, the Index server is unable to propagate (read ‘”copy”) the index files and configuration to the query servers because the shared folder “searchindexpropagation” is missing since it could not be created at setup time.
Martin Kearn (MS MCS Consultant in UK) also reports the issue in locked-down environment (Windows Server 2008 in particular): http://blogs.msdn.com/martinkearn/archive/2008/10/29/manually-configuring-search-propagation-location-using-stsadm.aspx.
Talking about Martin Kearn, make sure you update your RSS Reader with the address of the new blog run conjointly with all UK SharePoint MCS Consultants: http://blogs.msdn.com/uksharepoint/
And finally, even the SQL Server cluster decided to bring its own set of issues, consequently bringing our SharePoint farm down…
Fortunately this one was easier to troubleshoot since it is almost and “old friend”: Cannot generate SSPI context.
The 3 resources hereunder will help tracking the root cause of the problem:
This interesting troubleshooting day reminded me Mr Spock saying “Logic, logic, logic. Logic is the beginning of wisdom, not the end”. This was is Start Trek VI: The Undiscovered Country. My favorite ST movie with the TOS crew. Christopher Plummer playing General Chang was simply great!