SharePoint 2010 – Clearing the Configuration Cache

http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx
There were many common issues that could occur in WSS v3 and MOSS that would require you to clear the configuration cache on your servers. While less common, these issues can still turn up occasionally on SharePoint Server 2010 (And Foundation). While the resolution for these issues might be the same, the steps are a bit different. The main thing to note is that the Configuration Cache is located in a different directory on Windows Server 2008 then it was in Windows Server 2003. The new path for the Configuration Cache under Windows Server 2008 is: %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\<GUID> The overall steps remain largely the same:

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 SharePoint 2010 Timer, and then click Stop.
   3. Close the Services console.
2. On the computer that is running Microsoft SharePoint Server 2010 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:
4. %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\GUID
5. Notes
1. The %SystemDrive% system variable specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
2. The GUID placeholder specifies the GUID folder. There may be more than one of these.
3. The ProgramData 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.
4. You can also simply type this directly in the path if you do not want to show hidden files and folders.
6. Back up the Cache.ini file. (Make a copy of it. DO NOT DELETE THIS FILE, Only the XML files in the next step)
7. Delete all the XML configuration files in the GUID folder (DO NOTE DELETE THE FOLDER). Do this so that you can verify that the GUID folders content 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.
8. Double-click the Cache.ini file.
9. On the Edit menu, click Select All.
10. On the Edit menu, click Delete.
11. Type 1, and then click Save on the File menu. (Basically when you are done, the only text in the config.ini file should be the number 1)
12. On the File menu, click Exit.
13. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Start.
    3. Close the Services console.
14. 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.
15. 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.
16. Check in the GUID folder to make sure that the xml files are repopulating. This may take a bit of time.

For the original steps for clearing out the configuration cache in SharePoint 2007, there are many articles that cover the steps, one of them is the following: http://support.microsoft.com/kb/939308

Sharepoint diagnostic studio (SPDIAG) performance counters have not been provisioned

The error seen as some of the counters  used to create these reports are not added to the  SP Diagnostic Performance  counters .  Below are the steps that fixed the issue in my environment .

1. From the SharePoint Manage shell  run the following commands to add missing SQL counters

Add-SPDiagnosticsPerformanceCounter –category SQLServer:Locks –counter "Average Wait Time (ms)" –allinstances -databaseserver

Add-SPDiagnosticsPerformanceCounter –category LogicalDisk –counter "Disk Reads/sec" –allinstance -databaseserver

Add-SPDiagnosticsPerformanceCounter –category LogicalDisk –counter "Disk Writes/sec" –allinstance –databaseserver

2.  Run the following command to ensure the new counters added are visible in the list , You should get response as below

Get-SPDiagnosticsPerformanceCounter | where  {$_.providername -eq "job-diagnostics-performance-counter-sql-provider"}| FL

InstanceNames               : {_Total}

MonitorAllInstances         : False

CategoryName                : Processor

CounterNames                : {% Processor Time}

LocalizedCategoryName       : Processor

ProviderName                : job-diagnostics-performance-counter-sql-provider

UpgradedPersistedProperties : {}

InstanceNames               :

MonitorAllInstances         : False

CategoryName                : Memory

CounterNames                : {Available Mbytes}

LocalizedCategoryName       : Memory

ProviderName                : job-diagnostics-performance-counter-sql-provider

UpgradedPersistedProperties : {}

InstanceNames               : {*}

MonitorAllInstances         : True

CategoryName                : LogicalDisk

CounterNames                : {Avg. Disk Queue Length, Avg. Disk sec/Transfer,

                              Disk Reads/sec, Disk Writes/sec}

LocalizedCategoryName       : LogicalDisk

ProviderName                : job-diagnostics-performance-counter-sql-provider

UpgradedPersistedProperties : {}

InstanceNames               : {*}

MonitorAllInstances         : True

CategoryName                : SQLServer:Locks

CounterNames                : {Average Wait Time (ms)}

LocalizedCategoryName       : SQLServer:Locks

ProviderName                : job-diagnostics-performance-counter-sql-provider

UpgradedPersistedProperties : {}

InstanceNames               : {}

MonitorAllInstances         : False

CategoryName                : SQLServer:Latches

CounterNames                : {Average Latch Wait Time (ms)}

LocalizedCategoryName       : SQLServer:Latches

ProviderName                : job-diagnostics-performance-counter-sql-provider

UpgradedPersistedProperties : {}

3. Restart the Timer service on  the WFE used to run SPDIAG .

4.  Launch the SQL Diagnostic Studio again , Click on New project & create the project with same name again .  This removes the old project & all the provider configurations are  re-initialized .

5.  The “SQL overview Report” should now work  without throwing any errors .

Thanks!!

---

Regards,
Manas Biswas
Microsoft Online Community Support


Please remember to click 'Mark as Answer' on the post that helps you or click 'Unmark as Answer' if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Troubleshooting SharePoint user profile service – Replicate Directory Changes

http://sriramkunapuli.com/2012/01/04/troubleshooting-sharepoint-user-profile-service-replicate-directory-changes/

I am actually trouble shooting one of the SharePoint 2010 newly setup Service Farm which is causing issues during Replicating the user profile from Active directory.
One simple step that the Administrator of the Farm who installed it forgot was, giving the “Replicate Directory Changes” permission to the user account which is configured as the administrative account for the User Profile Service Application. In order to make the Fore Front Identity Manager properly do it’s job of replicating the content this permission has to be given to the account which is the administrative account that does the replication BETWEEN the active directory and SharePoint.
Login to the Active Directory Server (i am assuming Windows 2008 R2) and perform the following steps to give the permissions.
1) Launch “Active Directory Users and Computers”
2) Right click on the domain which needs to be replicated and click on properties.
3) Click on “Delegate Control”, Add the User Profile administrative account user and click on next.
4) Make sure ”This folder, existing objects in the folder and Creation of new objects in the folder” radio button is selected and click on Next
5) “General” checkbox is checked by default, and from the list of permissions select “Replicating Directory Changes” checkbox and click on next and finish.
This will grant the administrative account to perform the replication of the objects between Active Directory and SharePoint.