"The path for the index location is not valid"

"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

I cannot open my sharepoint site on server, but works on clients

Suppose you run into problems with your machine that you can never open the SharePoint site on your server
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

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

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

Basics of DNS and MX Records

An introduction to DNS records

When your Web browser checks the DNS server to find the IP address of the server hosting the Web site, it's actually looking for a record that lists the IP address of the Web site. DNS servers generally contain many different types of records. While it is beyond the scope of this tutorial to discuss all of them, here is an overview of some of the more important DNS records you should know about.

Start of Authority (SOA) records
There are often multiple DNS servers that service a domain. Multiple DNS servers might be used for load balancing, fault tolerance, or both. But, only one DNS server within a domain is considered authoritative.

The authoritative DNS server contains a read/write copy of the records database. Non-authoritative DNS servers are read-only. A Start of Authority (SOA) record points to the domain's authoritative DNS server. It also contains a sort of sequence number that is updated every time a change is made to the records contained within the zone. This helps non-authoritative DNS servers stay in sync with the authoritative DNS server.

Name Server (NS) records
A Name Server (NS) record is similar to an SOA record in that it points to the domain's DNS servers. The similarities end there though. Each DNS server in the domain gets its own NS record, regardless of whether it is authoritative or not.
Host records and Alias records

Probably the most common type of DNS record is a Host record (also called an A record). A Host record is simply used to associate a computer on your network with an IP address.

For example, I have a server on my network named RELEVANT. I therefore also have a Host record on my DNS server that links the name RELEVANT to the server's IP address.

It just so happens that the server RELEVANT is hosting a Web site on my domain. However, when people want to visit my Web site, they do not enter relevant.brienposey.com, even though that is the fully qualified domain name (FQDN) of the server hosting the Web site.
Instead, they enter www.brienposey.com. This is where the Alias record (also called a CNAME record) comes into play. An Alias record's job is to associate an alternate name with a computer for which there is already a Host record. For example, suppose that the host record for relevant looked like this:
Relevant Host (A) 147.100.100.97
When someone enters www.brienposey.com, I want them to be directed to the relevant.brienposey.com server. Since there is no server on the network named "www," I set up an Alias record that associates www with relevant.brienposey.com. The Alias record looks something like this:
www Alias (CNAME) relevant.brienposey.com

MX records
An e-mail message finds its way to its destination via an MX record.

An e-mail address is made up of a recipient name and a domain name (recipient@brienposey.com). I already explained how DNS queries are used to locate a DNS server for a specific domain. The process works exactly the same way when you send an e-mail message to a recipient in another domain.

The difference is that your mail client isn't interested in the IP address of your Web server -- it needs to know the IP address of your mail server. That's where the MX record comes in.
An MX record stores the IP address of your SMTP server, so e-mail clients can determine where a message should be sent. They simply perform a DNS query against a domain's MX record to get the IP address of the organization's SMTP server.


How to create an MX record ??

1. To create an MX record on a Windows Server 2003 DNS server, select the DNS command from the server's Administrative Tools menu to open the DNS console.
2. Navigate through the console tree to DNS -> your server -> Forward Lookup Zones -> your domain.
3. Right click on the listing for your domain and select the New Mail Exchanger (MX) command. You will see the New Resource Record dialog box shown in Figure A.

Figure A

Use the New Resource Record dialog box to create an MX record.

• The first field on this dialog box asks for the name of a parent or child domain. In most cases, this field will be left blank.
• The fully qualified domain name (FQDN) is filled in automatically.
• Just below that is a field asking for the FQDN of the mail server -- not the mail server's IP address.
• What this means is that, unless you have a Host record in place for the mail server, the MX record isn't going to work The last field on this dialog box is a priority number.
• If you are only planning on using one MX record, you don't have to worry about changing this number. But many organizations (including my own) have multiple Exchange servers.
  
  How to set up a Host record ??
  
  MX record won't work without a Host record in place, so let me explain how to set one up:
• In the DNS console, right click on your domain listing and select the New Host (A) command from the shortcut menu to view the dialog box shown in Figure B.
• Enter the server's name in the Name field. Be sure to use the simple name, not the fully qualified domain name (relevant -- not relevant.brienposey.com).
• Now enter the server's IP address and click the Add Host button

Figure B

You don't have to worry about creating a PTR record unless you plan on supporting reverse DNS queries. Also, you usually don't want to check the "Allow Any Authenticated User to Update DNS Records" checkbox for security reasons.