Wednesday, September 9, 2009
Search does not work for me since I splitted the indexer and the query server
I came to know that we were not able to search the portal site since we decided to have a dedicated Search server in the farm.
The environment was
1 Application server 32 BIT Windows Server 2008 also running search query service
1 Search server 32 BIT Windows Server 2008 running Search Indexing Service
1 Database server which was SQL 2005
Interesting catch was that everything was running under FQDN
The search started getting rude to us since we added a search server to the farm and gave it an Indexer role. also the search was set crawl all the Dedicated WFE (which might not be a good idea)
First thing you have to check is the Crawl logs, which might give you a better direction, mine gave me error as - could not access the url
The site was browse able on the client and the application server
we RDP'd to the Index server and tried browsing the site & it did not show up
Tried pinging, tracert, nslookup; no response- by this time we were sure that it was a network problem
What's the catch ?
The Domain Controller was running on Windows Server 2003, which means IPv4 we saw that Sharepoint was running on Server 2008 which is IPv6.
when you give role to a server as Indexer it writes entries to the host file with the url of the sites and from there we saw that it was IPv6
we disabled the IPV6 networking layer on Sharepoint and the sites were now browseable and searchable
checkout the following links to support that :
http://support.microsoft.com/kb/215383
http://technet.microsoft.com/en-us/library/cc748826.aspx
Golden Point to remember:
Incase you have separate Query and Index server in the farm make sure that the site should be up and browse able on the Indexer server
Wednesday, September 2, 2009
"The path for the index location is not valid"
I recently faced this issue with the Sharepoint on the Central administration page that gives "The path for the index location is not valid" error message on the Manage search settings page on Application management
Reason:
================
The problem occurs when you have changed the default location of the index file path
Resolution:
================
+ Either you can try bringing the index location back to where it was
+ Try stopping and starting the Osearch service give it the new location, and start it again, to do this make command line your friend.
+ To stop and start WSS search with command line use http://technet.microsoft.com/en-us/library/cc288507.aspx
+ To stop and start Office search with command line use http://technet.microsoft.com/en-us/library/cc262920.aspx
+ Try giving WPG group as full permissions on the index file location folder
+ Also give permissions to the C:\windows\tasks folder
+ As its a system folder and it will not give you permissions to edit the attributes on the command prompt run attrib -s C:\windows\tasks the go to security tab and add permissions and then again on command prompt run attrib +s C:\windows\tasks, to get the system folder attributes in place
Assume that the new index location you have provided is Drive D,
so go to the D drive and add the network service and the Worker Process Group (WPG) group as the following permissions listed
Permissions:
Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes, and Read Permissions
And I bet it going to work, if you are wondering why, this is because O search is controlled by a service named Office server web services and this service runs with the service account as Network service.
you can determine this from the IIS
Wednesday, August 19, 2009
I cannot open my sharepoint site on server, but works on clients
There might be several reasons why you may run into this
First question: do you have a Host header on the site?
Second: did you configure the site in a Host header mode?
Third : Is the site browse able on the server with servername ?
If you answer yes to all three I guess I know what to do, also even if you answer no to the third one we are still good….
Follow the magical KB http://support.microsoft.com/kb/896861 and disabled loopback check
Steps to do that are as follows:
Disable the loopback check
Follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value.
4. Type DisableLoopbackCheck, and then press ENTER.
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor, and then restart your computer.
Now it is okay if you do not restart the machine, sometimes it just takes it and the site should be then browse able on the server
Thursday, June 25, 2009
Setting full anonymous access for a document library
If you have a SharePoint site which is running on full anonymous access and you want a document library to run on anonymous access too, that will not be possible because by design SharePoint will only allow the anonymous users to only view the contents of a document library and not add anything to it
If you want the anonymous users to be able to add the documents as well to the library you will have to perform an additional task
Friday, June 19, 2009
SPD workflow Failed on start (retrying)
I have been wrestling with this issue for about 60 days, the issue occurs when you create a simple OOB SPD workflow or even a Nintex workflow.
The solution to this is two parts
PART I
=================
The service account should be a part of
1. Looked at the groups in the local machine
· WSS_WPG
· WSS_ Restricted
· WSS_Admin_WPG
· IIS_WPG
2. Checked on the SQL management studio > security > logins > Service account > properties > server roles were given as dbcreator > security & system admin > public
Looked in user mappings the service account was set db owner
3. >> Looked in the application content database in SQL
service account should be is a db owner
4. In Central Admin page > policy for web application > add service account as full control
5. CA > operations tab > update farm administrators group > service account is added there
6. looked in the site > site settings > site collection administrator
7. looked in the component services > dcom config > IIS admin service > security > added the service account to launch and activation > access permissions > and Configuration permissions .
After doing all these settings the service account must have all the require permissions
PART II
===============
Second part of the solution is change the service account from the central admin page & run an IIS reset
this is the main key and you will have to compulsorily do this to resolve the issue
hope it works for you
