User Profile Incremental Job Not Set

I had this same issue and this blog post fixed it. If your synchronization schedule says Not Set, change the timer job from hourly to daily. This worked for me also.

User profile incremental sync job doesn’t display schedule correctly

Circumvent List View Threshold in SharePoint 2010

I recently ran across an issue on one of our user’s document library where the library had once again exceeded the list view threshold defined in resource throttling in Central Admin. I raised it from 5000 to 50,000 and they now have 50,712 items in the library. I was creating filtered views for them as is suggested by Microsoft but they were still receiving the list view threshold error. What I found was even if you filter a list, unless the column is indexed the web front end still pulls all the data out of the database and then filters the results to send the user their view. What you have to do is go to your library settings, and under the columns you will see ‘Indexed Columns’. Here you will add which columns you are using for your view filters. Now when you pull a filtered view up only the data needed to parse the list to the user is pulled from the database, and your list view threshold is not hit.

New SharePoint 2010 web application not being created on all web front-ends

I recently had an issue where when I created a new web application in central admin, it would show up on my application server (has web application service running also) but it would not show up on either my two dedicated web front-ends. I tried everything I could and eventually logged a case with Microsoft. The procedure they sent me was this:

1) Delete the newly created web application
2) Stop SharePoint adminstration service from services.msc on all SharePoint servers
3) Run stsadm -o execadmsvcjobs
4) Start SharePoint administration service from services.msc
5) Create new web application

Web app should now show up on all servers running the web application server. If this does not work you can alternately try clearing the SharePoint cache using the following procedure: http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx

User Profiles Not Updating in MOSS 2007 Site Collection

We noticed that when users’ information was updated in AD that it was updating in the user profiles in shared services but was not updating in site collections. Using troubleshooting steps from this Microsoft KB article we found the issue. Most, if not all, of our content were stuck in “preparetomove” status. We found this by running the following query on the SQL instance that hosts our MOSS 2007 content DB’s:

Select Name from Sharepoint_Config.dbo.Objects  with (nolock)
 where id in (Select Distinct ContentDBId from SharedServices_DB.dbo.SiteSynch with (nolock) where Moving = 1)

You will want to replace the ShareServices Content DB with your content DB name and also the SharePoint_Config DB name. When we ran this command we found that most of our content DB’s were in preparetomove status. We cleared that status with the following stsadm command:

Stsadm -o preparetomove -contentdb <SQL Server Name:Database Name> -undo

We had an issue with this command at first because it could not find the content DB’s. As it turned out we are using SQL aliases on the SharePoint servers so we used this command to find where the content DB’s were actually pointing:

stsadm.exe -o enumcontentdbs -url <URL name>

After running these commands to clear all prepapretomove flags on the conntent DB’s, and verifying this by rinning the first queiry in this post, we then initaited a full profile import from sharedservices.

There’s also some good info in this TechNet article if the above does not help: http://blogs.technet.com/b/nishants/archive/2010/08/23/troubleshooting-user-profile-sync-issues-in-office-sharepoint-server-2007.aspx

 

IIS 7.5 32-bit App Pool

When running an app as a 32-bit app in IIs 7.5 you may experience the app pool stopping every time you try to browse the site. We kept getting a 503. I added the app pool identity to the framework directory with read permissions and this did not help. It turns out that the Framwork64 machine.config had the Users group with read rights. The Framework\v4.xxxx machine.config had explicit permissions only and was not inheriting anything. I set it to inherit which gave read rights to the framework directory. This fixed the issue and the app pool remained started.

SQL Server Resource Throttling

I ran across a SQL 2008 server recently that from day to day was having issues with memory allocation to several SQL server instances. This is a development server so the load is varied depending on the work being done that day but we do have several other SQL servers and clusters that this information will also pertain to. Here is a summary of how I fixed the memory allocation to these instances to stabilize the servers:

If the SQL server has multiple instances check the ‘memory’ setting inside management studio for each instance. Default is 2147483647 MB. So if you have multiple instances they will each be set to this. The problem comes in with how SQL allocates a buffer pool of memory as its resource consumption increases, or perhaps better stated, the lack of it releasing those resources once it’s done. What we see is when memory allocation increases due to SQL processing transactions, the database engine will increase the buffer pool, but once the load decreases the buffer pool holds onto that memory. Typically when you look at the resource consumption on a single instance server you’ll see that single instance using almost all the memory on the server, typically 99% of it. So when you have a multi-instance SQL server those instances fight for that memory. If instance A happens to grab 80% before instance B can get what it needs then you only have 20% left for instance B. Until the SQL service is restarted you will never release that memory for other processes. I found this to be the case on this particular server where I have an instance for MOSS 2007 and an instance for SharePoint 2010. What was happening was since the utilization is currently higher on MOSS 2007 that instance was allocating almost all the memory on the server for its sqlserver process and leaving none for the SharePoint 2010 instance. The SharePoint 2010 instance was left running with very little memory, whatever scraps were left, and when it really needed to ramp up it could not, and was choking. Furthermore it was choking other processes on the server to the point you could hardly log in let alone run management studio (I had to run it remotely). So what I did was increase the memory on the server to 64 GB from 32 GB. But I also subtracted 8 GB from that total to leave for the OS, and then set the max memory on each instance to be 28 GB. I checked it the next morning and the MOSS 2007 instance is using all 28 GB I allocated for it, as I suspected, and the SharePoint 2010 instance is using about 6 GB. Now should the SharePoint 2010 instance need to run some heavy queries it will have the memory needed to ramp up its buffer pool and run the transactions, whereas if I had not limited the MOSS 2007 instance it would have ran its buffer pool all the way to the limit of the server RAM total, 64GB. Meanwhile you can log onto the server with ease and run other utilities including management studio without issues. The best part is these values can be changed on the fly in SQL without a reboot. My plan now is to monitor these instances and the server itself and throttle down the memory allocation on each instance to a manageable level and decrease the memory allocated to the server to reclaim some of those resources.

Just something to keep in mind when the call goes out next time for “MORE RAM!”. Contrary to popular belief, we have to pay for that stuff.

Beware of -stsadm -o deleteconfigdb

Our scenario was this: we moved our farm to new hardware. We followed this TechNet article on how to move the databases and then  use cliconfg.exe to set up a SQL server alias on the farm machines. What we noticed was that the config db was still referencing the old SQL server when we looked in central admin. So we followed another article on running the deleteconfigdb operation and then the setconfigdb operation, but did not test it on a development environment first. The deleteconfigdb operation completed successfully, however, the setconfigdb operation did not. We could not get our renamed server’s config database to attach. We ended up having to rebuild our farm and installing all features again. This was a long arduous task just to get the config db server name updated in Central Admin. And in the end, the server name was never updated. It still references the old server. I do not recommend running these commands to accomplish this and before running this command at all I recommend you run it in a test environment to make sure it will work for you.