Modifying the alternate access mapping

Hi Fellow SharePointers J

This week I encountered a problem from an unusual source – AAM (Alternate Access Mapping)

I Tried to edit one of the records when I got this error :

 "An update conflict has occurred, and you must re-try this action" .

I'll let the Microsoft description to do the explanation here since it is well put:

"This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server."

The way to perform this is as following:

1. Stop the Timer service. To do this, follow these steps:
   1. Click Start, point to Administrative Tools, and then click Services.
   2. Right-click Windows SharePoint Services Timer, and then click Stop.
   3. Close the Services console.
2. On the computer that is running Microsoft Office SharePoint Server 2007 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
3. In Windows Explorer, locate and then double-click the following folder:
   Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID
   Notes
   • The Drive placeholder specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
   • The GUID placeholder specifies the GUID folder.
   • The Application Data folder may be hidden. To view the hidden folder, follow these steps:
     1. On the Tools menu, click Folder Options.
     2. Click the View tab.
     3. In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
   • In Windows Server 2008, the configuration cache is in the following location:
     Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
4. Back up the Cache.ini file.
5. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
   
   Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
6. Double-click the Cache.ini file.
7. On the Edit menu, click Select All.
8. On the Edit menu, click Delete.
9. Type 1, and then click Save on the File menu.
10. On the File menu, click Exit.
11. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click Windows SharePoint Services Timer, and then click Start.
    3. Close the Services console.
    Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
12. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
13. Click Start, point to Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.
14. Click the Operations tab, and then click Timer job status under Global Configuration.
15. In the list of timer jobs, verify that the status of the Config Refresh entry is Succeeded.
16. On the File menu, click Close.

Source : KB939308

I used This Method lots of times and it always saved me :-)

Backup \ Restore - SQL Permissions

Hello again,

The case :

Sometime this month I was performing a restore from the MOSS GUI, and I got the following error :

                                              

It turned out to be an SQL Permission Problem, since the "SQL guys" gave me DB Creator and not SYSADMIN Permission as needed, I was able to create a new DB but what I couldn't do is to set a reference to it in the MASTER db.

Conclusion – always check your Permissions before you start a backup \ restore

"Service Unavailable"

Hi People!

First….The case

Recently I "inherited" a Portal server 2003 (wooooha), and so I went on and tried to browse to the portal URL, but what I got was "Service Unavailable".

The steps I did:

First of all I checked to see if the site itself and it's application pool are running.

Once I saw they were running well, I figured it must be a Permission problem.

So in order to save me some time I googled it and fair enough I found a Microsoft KB.

To save you guys the need to go into the link I'll tell you it’s about how to make sure the Permissions groups are in order and how to change the permissions in the IIS (6.0)

Here are the steps needed to be done :

1. Verify that the application pool is configured for the virtual server. The default application pool is MSSharePointPortalAppPool.
   
   Follow these steps to determine the application pool that the virtual server is using:
   1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
   2. Expand ServerName, expand Web Sites, right-click the virtual server, and then click Properties.
   3. Click the Home Directory tab.
      
      The application pool that is configured for the virtual server is listed in the Application pool box.
   4. Click OK.
2. Verify that the password for the application pool account is correct. IIS does not automatically poll password changes in Active Directory directory service. If the application pool account is a domain account, and the password expires, you may receive the error message that is described in the "Symptoms" section of this article after a new password is specified for the account.
   
   Follow these steps to verify that the password for the application pool account is correct:
   1. In Internet Information Services (IIS) Manager, expand Application Pools.
   2. Right-click the application pool that is configured for the virtual server (for example, right-click MSSharePointPortalAppPool), and then click Properties.
   3. Click the Identity tab.
   4. In the Password box, type the password of the application pool account that is listed in the User name box, and then click OK.
   5. In the Confirm Password dialog box, type the password again, and then click OK.
3. Verify that the application pool account is a member of both the IIS_WPG group and the STS_WPG group on the server:
   
   Use one of the following methods as appropriate to your situation:
   1. If Windows SharePoint Services 2.0 is installed on a member server:
      1. Click Start, point to Administrative Tools, and then click Computer Management.
      2. Expand Local Users and Groups, and then expand Users.
      3. Right-click the account that is used by the application pool for the virtual server, and then click Properties.
      4. Click the Member of tab.
         
         Verify that both IIS_WPG and STS_WPG appear in the Member of list. If one or both groups are not listed, add the IIS_WPG group, the STS_WPG group, or both groups (as appropriate) to the list.
   2. If Windows SharePoint Services 2.0 is installed on a domain controller:
      1. Start Active Directory Users and Computers.
      2. Expand Users.
      3. Right-click the account that is used by the application pool for the virtual server, and then click Properties.
      4. Click the Member of tab.
         
         Verify that both IIS_WPG and STS_WPG appear in the Member of list. If one or both groups are not listed, add the IIS_WPG group, the STS_WPG group, or both groups (as appropriate) to the list.
4. Restart IIS to recycle the application pools:
   1. In Internet Information Services (IIS) Manager, right-click ServerName, point to All Tasks, and then click Restart IIS.
   2. Click Restart Internet Information Services on ServerName, and then click OK.

 

And that's all, I hope you found this post helpful.

AntiVirus

In this post I will refer to a matter which usually slips out of people's minds when they are installing a SharePoint farm, and that is the Antivirus.

Anti-Viruses that use File-Level Scanning basically scan everything that is being used by the OS or apps, that's good for protecting from viruses but what about SharePoint in this deal?

SharePoint loses Performance on this matter if you don't exclude some folders.

Microsoft has indicated in a KB article exactly what is to be excluded, keep in mind to the changes in OS and 64 VS 32 bit servers.

The main folders are:

C: \Program Files\Common Files\Microsoft Shared\Web Service Extensions

C: Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

C:\Program Files\Microsoft Office Servers

C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files (on 64 Bit Servers)

C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config C:\Windows\Temp\WebTempDir

C:\WINDOWS\system32\LogFiles 

C:\Windows\Syswow64\LogFiles (on 2008 Servers) 

For reference here is the KB article link.