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.

Daylight Saving Time

Hello Everyone,

This post is mostly aimed to my Israeli crowd (because this problem concerns them the most).
It's about the Daylight saving time issue in MOSS and Sharepoint 2010 in the year 2011.

Sharepoint (or moss) dosen't look at the OS date as regarding to Daylight Saving time, it looks at an XML file located in : C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Config\TIMEZONE.xml.

This years Changes include the following changes :

<.Bias>-120<./Bias>

<.StandardTime>
<.Bias>0<./Bias>
<.Date>
<.Month>9<./Month>
<.Day>2<./Day>
<.Hour>2<./Hour>
<./Date>
<./StandardTime>
<.DaylightTime>
<.Bias>-60<./Bias>
<.Date>
<.Month>4<./Month>
<.Day>1<./Day>
<.Hour>2<./Hour>
<.DayOfWeek>6<./DayOfWeek>
<./Date>
<./DaylightTime>
<./TimeZone>

That's because the change is due on the night between Thursday and Friday at 2 AM in the date 4.1.2011.

There is also a little bug that a co worker of mine showed me, you can view it in his Blog.

For those of you who dosen't understand Hebrew i'll reveal the bug here.

Israel resides in the GMT+2 Time Line, which means we are -120 minutes away from the Grinich line.

Therefore the data -120 <.Bias>-120<./Bias>

Month being the month the clock changes to daylight saving time  <.Month>4<./Month>

Hour representing Hour <.Hour>2<./Hour>

DayOfTheWeek representing the day of the week it will change. <.DayOfWeek>6<./DayOfWeek>

And get this : DAY representing the week the change will occur (yes the week not the day) <.Day>1<./Day>


The changes to the XML file needs to be done on all the servers in the farm, and don't forget to backup your old XML files just in case.


Here is what Microsoft have to say about the Issue.

Happy transition to the year 2011 DST :-)

Office Search Service stuck on 'Stopping'

Today i faced a pretty persistent problem, the Office Search Service was stuck on "stopping" as you can see in the next picture :

What i did was to change the Permissions on the Office Search Service to "LOCAL SYSTEM" (By going to Services.msc), then i disabled the service. the next step i took is the following STSADM command :
stsadm -o osearch -action -start
Which still isn't good enough. now we have to give the office search service the right permissions again.
It should be the Search user you have in the farm.
After the permissions are in order enable the service and run the STSADM command we tried before and that should do it for you :

 If the Exact way that i described the stages doesn't work for you try doing the same stuff i did just in different order because i did them so many time i might be confusing the order of the operations :-)

Sharepoint Versions

Sometimes we come across a Sharepoint farm with an unrecognized Build number.

Fortunatly some one has put in the effort  all ready and wrote all the versions down :

The list for Sharepoint 2007 can be found here.

And the list for Sharepoint 2010 can be found here.

Cause you don't want to get the Wrong Build Number....

GAC Folder View

There are allot of ways that can allow us to View the GAC folder as plain File System Folder. (usefull if we want to simply copy\paste files from that folder)

The easiest way i have found that dosen't require mapping drives or even changing the registry is this :

Go to Start > Run > c:\windows\assembly\GAC_MSIL

Just know that you cannot use this path as a shortcut Because the server will just close the window for security reasons. so what you can do is write this path on a txt file and copy paste it to the run folder anytime you need it (or you can just remember the path like i do)

Short And Sweet :-)

Disable Loop Back Check

On so many errors and event Viewer Logs i encountered a problem that needs this Registry change so i won't Write a specific problem rather then just post the solution, i use it on all my servers even before i get and error in the Event Viewer.


To set the DisableLoopbackCheck registry entry to 1, follow these steps on the client computer:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey: 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. Exit Registry Editor.
8. Restart the computer (otherwise the solution won't work for you)

Consider this as a best practice.

New Username

Hi Everyone,

We all know that from time to time users will have their Username changed in the Active Directory.
What happens behind the scenes is that their GUID is changed in the Sharepoint DB, and that could cause those users to lose the Permissions granted to them for site, lists etc.

Well...Fear no more our friend the stsadm comes to the rescue. what you should do is run the following command :
stsadm -o migrateuser -oldlogin DOMAIN\OldUserName -newlogin DOMAIN\NewUsername -ignoresidhistory

This command will Migrate all the Permissions the old username had and transfer them to the new username you provided in the stsadm command.

I'm sure someone will find this helpful :-)