This is a SharePoint 2010 problem a client was facing. Essentially they had installed SharePoint and were in the process of manually configuring their services. They had setup the Search Service Application, but when the went into the Search Administration, the got the error below.
The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ‘c200182e-0520-4f00-bd2c-50321fc377e8′ in search application ‘Search Service Application’ is in a good state and try again.
There are various posts out on the Internet describing a resolution for this. But prior to attempting any of those, please check to see if your SharePoint Foundation Search is up an running. If it is not, then do start it and try again.
Always remember to lookout for the obvious prior to digging deeper, and it will save you time and grief.
This is a SharePoint error that occurred on a SharePoint 2010 environment post-install. Essentially, the user tried running the SharePoint Configuration Wizard to get things going but got the error message below.
In order to resolve this, you will need to give the service account READ access to all Authenticated Users.
Basically, on Active Directory Users and Computers, ensure that Advance Features is selected from the View menu. Then, open the property window of the desired account, select the Security tab and find Authenticated Users. Finally, select Authenticated Users and give them READ access.
Microsoft has release a knowledge base article for this, see KB2463865 for full information.
STEP 1: Enable xp_cmdshell
From you desktop navigate to Start –> Program Files –> Microsoft SQL Server –> Configuration Tools –> Surface Area Configuration –> Surface Area Configuration for Features
Click on the SQL Server Instance (Database Engine), then click and tick xp_cmdshell to enable this.
STEP 2: Map the Drive
Run a new SQL query to mapped the drive as such EXEC xp_cmdshell ‘net use <drive> <share>’
For example, I would like to map my share on pc01 called Backups to drive Z. My query would be as such:
EXEC xp_cmdshell ‘net use Z: \\pc01\Backups’
STEP 3: Verify the Drive
Run the following SQL query EXEC xp_cmdshell ‘Dir <drive>’
Based on my example, this would be
EXEC xp_cmdshell ‘Dir Z:’
Note: This mapping is not permanent. If required, then create a stored procedure that runs it when appropriate.
If the above scenario is a one off requirement, then don’t forget the steps below.
STEP 4: Delete Mapping
Run the following SQL query EXEC xp_cmdshell ‘net use <drive> /delete’
Based on my example, this would be
EXEC xp_cmdshell ‘net use Z: /delete’
STEP 5: Disable xp_cmdshell
As per-step1 navigate to your database instance, then click and untick the xp_cmdshell option to disable it.
This is more of a note to self kind of post, but if it helps you as well then super. The Approval Status internal field name is _ModerationStatus and it is of type ModStat, which has internal values corresponding to the status. See table below:
These values can be used to help simplify things for us, for example if I was to use CAML and retrieve all Approved documents from a particular document library the query would look something like below.
<Where><Eq><FieldRef Name=’_ModerationStatus’ /><Value Type=’ModStat’>0</Value></Eq></Where>
My first post of the year, and it’s starts with a couple of Q&A’s.
Q: Where is the IIS administration.config file located?
A: It is under System32\inetsrv\config folder.
Note, this file can’t be edited using a text editor of any sort. It can be edited using code, the ServerManager class.
The ServerManager class requires the Microsoft.Web.Administration.dll
Q: Where is the Microsoft.Web.Administration.dll located?
A: It is under System32\inetsrv folder.
This is where you only get the Save and Cancel option from the dialog box, and no Open option. This is a security feature that prevents the application from opening and running unrecognised file types. To get around this, go to Manage Web Application in Central Administration. Then select the Web Application that represent the issue, and select General Settings. Under General Settings, change the Browser File Handling from Strict to Permissive. All done, no more problems with this now.
For some reason or another, I just could not get this option enabled/available. I had initially logged on with my SharePoint Administrator account, and then tried the Farm account as well. But nothing seem to worked, this option remained grayed out, with a message “This control is currently disabled”
Solution: Close down all browser sessions, then open up Central Administration site via-Run As Administrator. This did it for me, hope it helps you too.
If you ever get this error
From Central Administration, under Operation click on Services then select the Project Application server role option to see the Project Application Service. Start the service and all is good and pure in the world again.
Note, you may not see this service when other server role options are selected.
Configuring Reporting Services as times can be quite painful. If you ever had trouble in getting your Web Service Identity working, you’ll understand what I mean. At times creating a new application pool as opposed to using an existing one will work. But then, at times it will still fail. If this happens, then you would need to manually add in the account in the configuration file. See steps below for this:
- Navigate to \Program Files\Microsoft SQL Server\MSSQL.1\Reporting Services\ReportServer
- Find the rsreportserver.config file and open it for editing.
- Do a search for “WebServiceAccount” and then type in your account. E.g: <WebServiceAccount>myDomain\myAccount</WebServiceAccount> Remember! this account is your Application Pool identity account for Reporting Services.
- Save and close the file.
- Restart the Reporting Configuration Manager console and apply your Web Service Identity again.
- For SharePoint integration, we must ensure that the account has access to the SharePoint Configuration database. And that SharePoint Integration is selected on Database Setup.
I spent a whole day attempting to resolve why this was happening. Every time I opened my SharePoint site, I’ll get a 503 error and when I check the IIS Console, I discover that the corresponding application pool has stopped. I tried numerous different things, and I also tried the suggestion from this forum discussion.
Before we get into the suggestion described in the forum, let me quickly list out the steps that I eventually performed to get this working and things back to normal again.
- Uninstalled SharePoint.
- Restart Server.
- Remove Web Server Role (uninstall IIS).
- Restart Server.
- Add Web Server Role (install IIS).
- Install SharePoint.
- Restart Server.
- Run SharePoint Configuration Wizard.
- Remove Default Application Pool and Web Site.
Now, let’s get into the suggestion as described in the forum discussion mentioned.
The idea is to give your Application Pool Identity account “Log on as a batch job” rights via-your Local Security Policy console. This can be found under Local Policies –> User Rights Assignment.
If you discover that the policy has a slightly different icon to it, then be assured that it is being overwritten somewhere else. Opening up its properties will reveal that the options are all greyed out (disabled).
As explained the policy is being overwritten by the Default Domain Policy, which can be accessed on your Domain Controller, from the Group Policy Management Console. Click and select the Default Domain Policy for editing. On the new console navigate through Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment. On the right panel you’ll find the “Log on as a batch job” policy, open its properties then add the application pool account to it. All done.
I am a bit doubtful that this process would actually work in all environments. But I would definitely give it a try before opting for a rebuild of your SharePoint environment. Good luck, and try not to get frustrated (easier said then done!).