Hello there! This is the world of mystery errors you find in SharePoint Server, any version, and until this very moment several of the solutions are not always from Microsoft. They are solutions that someone figured out just by looking at the architecture a little while longer with a lot of head-scratching, lip-biting, coffee-drinking, and gum-chewing frustrations. SharePoint is an amazing technology that packs a lot of functionalities that would have been dubbed independent modules into one single application. In this scribble, I am going to reveal 5 mysterious errors in SharePoint and how to go about resolving them. Subsequently, this can be the first of a series of topics among error resolutions in all versions of SharePoint, specifically 2010. So let’s get right to it and reveal mystery error number one.
ERROR MESSAGE #1
“The install in progress conflicts with a previously installed Microsoft Office 2010 Server product”
SharePoint 2010 is fun and easy. I mean for example, years back working with Windows operating system installation was an arduous task. Deep blue screen, white lettered alphabets, few instructions, shortcut keys to answer either YES, NO, CANCEL, or PRESS ANY KEY TO CONTINUE, and the corrupted .dll files all plagued us till Win2k3. And then Vista came with the easiest “ungeeky” method of installation, and same for Win2k8. In the SharePoint side of things, it started off as easy in WSS until MOSS 2007 came into the picture and it was all a picture of Hiroshima and Nagasaki all afresh. Now we breathe some air of relief with SharePoint 2010 configurations made easy in one simple Wizard screen. If we thought it was over, we were all probably not very right.
With SharePoint 2010, installing, uninstalling, reinstalling, re-uninstalling is just so tempting at the slightest thought of problem but you will get bitten a few times, Language Pack is one and Office Web Access is another. These guys can ruin your 30-minute coffee break or you might never go at all.
What happened? Someone in the team downloaded a custom code, and installed it in my dev environment. This killed my Central Admin immediately. I wonder what was in the code! Every other site was working except my CA. SharePoint 2010 is tempting. I figured rather than looking for the problem, yank it off and reinstall after a proper backup. So, I uninstalled and began re-installing but just after the product key page, I got this.
This particular problem is caused by Language Pack. I had installed a French language pack because half my users are French speaking. So that language pack was important.
1. Stop the installation.
2. Go to Control Panel –> Programs and Features.
3. Identify the language pack for SharePoint.
Now you can proceed to install your SharePoint as normal, and your language pack later. Do this if you have a multilingual environment where you have to present the sites in the different user’s languages.
ERROR MESSAGE #2
“Error Failed to Connect to the Configuration Database: An Exception of Type System.ArgumentNullException Was Thrown. Additional Exception Information: Value Cannot Be Null Parameter Name: Service.”
So, here we were trying to expand the SharePoint 2010 farm a bit. The farm is comprised of one or more VMs sitting in an elaborate VMware infrastructure and a few physical servers hosting the databases. So the VM hosting the application services for SharePoint 2010 was kind of slow. It was decided to add a new one and yank the slow one out, or perhaps even leaving both of them in there, you know how cool it is for us to have more servers doing stuff, good for my ego. After going through the harrowing experience of missing locally and missing in xxxx servers and yyyy servers, and other annoying language pack issues, the box was finally ready. So, I fired up the SharePoint 2010 Products Configuration Wizard of Oz, and got this along the way, just the very first steps really:
Familiar it seems. Of course the error is not familiar, but getting errors from SharePoint is like our thing. I mean, if you don’t get any errors a few times a day you would begin to wonder “Am I doing things right?”Just kidding! But it’s true though. So, how do we resolve this?
Create an alias on the server for the SQL client. For some reason, this was just the solution. SQL Alias is something which you may have to create when you’re moving your database servers around. I had a requirement from the Windows Enterprise Team to move from an old database server to a new one. You will have to create SQL Alias on each web front and application server of SharePoint.
Click on Start > Run and Type cliconfg
Now enable TCP/IP Protocol.
Select TCP/IP and Click on Enable.
Click on Alias Tab.
Select TCP/IP from Network Libraries.
And enter the old database server name in Server Alias.
And set the Server Name to New Database Server Name.
ERROR MESSAGE #3
“An Exception of Type System.Reflection.TargetInvocationException was Thrown”
From the stables of SharePoint error-laden blockbuster features, comes another mysterious and annoying error, *[drum roll]*, *[special effects]*, *[camera up-close]*, *[camera drawback]*, *[more Star War effects]*.
This happens when you try to join a new server to a farm. And that is after you have battled the infamous install check which returned like 80 language packs problem, 120+ missing locally problem and the rest of the evil minions from SharePain hell. So, what do we do? How do we resolve?
You won’t believe this. It’s your NTFS drive letter causing this. Crazy! Just to be sure, open your ULS log file in the APPLICATION server and do a search for “directory name you entered is invalid“. If this returns a series of results (best if you use Notepad++) then that is the problem. What to do is take a look at the drive letter convention in your machines, and ensure your new server is consistent with the drive letters. So, if your APPLICATION server has C, D, E, F drives, ensure your new machine is named the same way. When done, re-run the Configuration Wizard again, and you should be fine.
ERROR MESSAGE #4
“SHAREPOINT 2010 ERROR: “Cannot start service SPAdminV4 on computer ‘.’.” error on SharePoint configuration wizard”
We can’t run away from it. We can only hope 20 years up to the line from now that SharePoint will stop giving us hair-tearing problems for no apparent known reason. I mean, we are just on our own thinking everything is fine and we get that problem that almost makes you feel like you really don’t know this thingy. Let me fill you in on the back story. I had this development server, was just fine and good. Then I travelled on a vacation that was really long and sweet, and I basically returned with a little more flesh around my middle region. I mean, that means I had a groovy vacation. Ok, I’m sorry, I lied. It wasn’t really a vacation; it was an official assignment that felts so well just like a vacation. I still remember the good times of it even now.
So, here I was, and then my boss says, “Hey James, um, please can you kindly send me the URL for the development server Central Admin?” So, just before I send it, I figured, um, let me just check it before sending it on, pretty normal cyclic redundancy check (CRC) of every geek’s brain, right? Well, it took forever, and it never came up, and after what felt like eternity, I get a pop-up asking me to setup central admin by running Configuration Wizard. I went like “What!” And then I checked some stuffs and I finally had to do the unthinkable, configure again. Well, it just went from fail… fail… to more fails… and fails. Then I got this log entries and messages that is the title of the mystery error #3 – THIS!
This entry is for those environments with the June 2012 CU for SharePoint 2012. This patch causes CRL (Certificate Revocation List) checks to be enforced, which in turn affects some native functionality of SharePoint AdminV4 service. In order to bypass the CRL Check for SPAdminV4 service start-up, the following steps are needed to be completed on each SharePoint server.
*Add a new computer policy which alters the options for retrieving certificate validation on a network.
* Add host file entries into the local computer host file.
To do this, alter the computer policy:
Click on Start àRun
Type in “gpedit.msc” and click “OK”
Expand Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies
In the Public Key Policy window displayed on the right pane, double-click “Certificate Path Validation Settings”
Click on the “Network Retrieval” tab
Check the box “Define these policy settings”
Uncheck “Automatically update certificates in the Microsoft Root Certificate Program (recommended)” and “Allow issuer certificate (AIA) retrieval during path validation (recommended”
Click on “OK”
- Close out of gpedit.msc console.
- ADD HOST FILE ENTRIES.
- Click on Start –> Run.
- Type in “C:\Windows\System32\Drivers\Etc” and click “OK“.
- Double-click the file “Hosts“.
Select “Notepad” as the program to open the file, ensure to uncheck the option that allows Notepad to open the file always show below:
- Insert the following lines into the hosts file
- 0.0.0.0 crl.microsoft.com
- 0.0.0.0 crl.verisign.com
- 0.0.0.0 ocsp.verisign.com
- 0.0.0.0 SVRSecure-G2-crl.verisign.com
- 0.0.0.0 SVRSecure-G3-crl.verisign.com
- 0.0.0.0 www.download.windowsupdate.com
- 0.0.0.0 SVRSecure-G2-aia.verisign.com
Save the file and exit Notepad (you may encounter a little problem here saving the host file depending on your system’s security hardness, a good way if you can’t save the host file back to the ETC folder is to copy it out from the secure path to your desktop, modify it as it is and copy it back to overwrite the original, OR open Notepad independently by right-clicking and selecting Run As Administrator, supply the credentials when prompted. Then use Notepad to open the HOSTS file by going to FILE à OPEN à browse to the hosts file, modify and click SAVE. It will save effortlessly). If you have gone this far in SharePoint, that shouldn’t be a problem to you, it’s pretty simple to work around. Problem solved.
ERROR MESSAGE #5
“An Unhandled Exception ‘system.security.cryptography.cryptographicexception’ Occurred in OWSTIMER.EXE”
I had this really slow and annoying SharePoint 2010 development server, bumped Visual Studio 2010 into it. Great idea it seemed then. Well, it still seems still in my eyes. Then, I had some application services not starting and just getting lost in limbo for like, forever. So, I re-installed the SharePoint 2010. Then one of my content databases refused to mount because of schema difference. So, I decided to install the March 2012 cumulative update (http://support.microsoft.com/kb/2597150) which took eternity, and then even so still in eternity, and intermittently between these two eternities I had gotten this error like forever:
If this error was coming up, perhaps when running some of my custom codes, and this debug suggestion came up, then no problem, I would proceed and debug. Visual Studio was trying to help me out with an unhandled exception by asking about launching debug. That was all well and good but I didn’t write the SharePoint code or the cumulative update code and so I had no plans to change it. So for as often as it popped up, it was the same number of times I told it to “get da hell outta da way!” Funny. Well for me, it wasn’t because it kept coming up like, “In your face Jimmy!”
Disable the JIT (Just-In-time Debugger) by following a few simple Registry Key changes. So many ways to do it and this is what I have done:
Deleted the following registry keys:
On a 64-bit operating system delete the following registry keys:
So that is where I wrap it up on these five ninja errors. Next time we will look at another 5 dark angel errors in SharePoint. #Arigato!