ACCESS DENIED when reading/writing to/from a file share (UNC) from SharePoint 2010

This week I was given the task of upgrading the Dynamics 2009 Enterprise Portal to SharePoint 2010 in order to use PerformancePoint etc. Having built a new SP 2010 farm, and deployed the Enterprise Portal role and site it was over to the development team for testing.

A number of issues cropped up, involving request timed out when trying to access the Dynamics database in list views, this was solved by giving users modify access to C:\Users\TEMP\AppData\Local\Temp as I could see the calls getting access denied in Process Monitor.

The second issue was a little more complicated and involved some code that reads/writes files from a remote file share using a UNC path.

When attempting to execute the code on the SharePoint server that uploads/reads these files, I trapped the path in Process Monitor and was getting 'ACCESS DENIED' for the read/writes.

On further inspection of the 'Details' Field, the sharepoint server was impersonating the user of the SP site rather than using the application pool account to read/write to the file server.

Unfortunately when you are using NTLM authentication a double hop such as this will not work (first hop is users browser -> SharePoint server, second hop Sharepoint server -> File server).

Looking at our older 2007 SharePoint/Enterprise portal configuration it became apparent that the this older server did not impersonate the user when calling the file server.

In order to prevent the SharePoint server from impersonating the user, I edited the web.config file for SharePoint site (C:\inetpub\wwwroot\wss\VirtualDirectories\sitename.domain80\web.config) and changed the value as follows:

<identity impersonate="false" />

Subsequently the hop is reduced to a single hop and the issue is then resolved.

Hopefully this will help someone else out who comes across a similar issue.

SharePoint 2007 Audience not updating and lost majority of members from AD groups?

OK so today someone reported an issue to me with the SharePoint audiences, one particular audience shrank from 400 users to 6.

The first thing to do when this kind of behaviour is experienced is to run a full profile import, and then the membership and BDC import will run minutes afterwards and should import the members of all AD groups into the SSP database.

I tried this solution and the group still showed 6 members when adding it to the audience, after restarting the indexer amongst many other things and multiple imports I was none the wiser.

I decided that there must be an issue with the AD group itself as it was clear SharePoint could not import it, so I modified the group description in AD and then ran another full profile import.

Sure enough, once the BDC/Membership import was complete, I added the AD group back to my Audience and it showed the correct number of members again.

Hopefully this will save someone ruining their afternoon trawling through various blogs and finding no answers!

Cheers,

Conrad

The specified SPConfigurationDatabase has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.

I am currently working on the task of upgrading our MOSS 2007 farm to SP2, and came across the following problem running psconfig (SharePoint Products and Technologies Wizard).

[SPConfigurationDatabaseSequence] [ERROR] [10/21/2010 1:01:41 PM]: Upgrade object too new (build version = 12.0.0.6327, schema version = 3.1.6.0). Current server (build version = 12.0.0.6421, schema version = 3.0.10.0).


[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: CanUpgrade [SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance] failed.


[SPManager] [ERROR] [10/21/2010 1:01:41 PM]: The specified SPConfigurationDatabase Name=SharePoint_Config Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.


The issue here is not to do with the service packs installed on any server in my farm, or any registry key settings, but the schema version of the configuration database. For MOSS 2007 this should always be 3.0.10.0 however in my case it is 3.1.6.0. The only probable explanation I have for this is a predecessor editing the database for some reason or other.

Unfortunately there is no supported method of dealing with this (you must never directly edit the SQL tables in SharePoint). Having spoken to Microsoft about this the only way forward is a fresh configuration database.

To do this, you will need to edit the registry key HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\SetupType - change this from b2b to 'CLEAN_INSTALL'

When you next run the P&T Wizard you will be asked if you wish to disconnect from the farm, and you can then run the wizard a 2nd time to create a new farm.

This can also be achieved via psconfig cmd on the command console.

This doesn't pose too big a problem for a fairly savvy SharePoint administrator - just re-create all your web applications and use stsadm -o addcontentdb -url -databasename and this will upgrade your content databases as you attach them,

Obviously you will need to restore any SSPs, and reconfigure any farm level settings that you changed from defaults, as well as enable any features/custom code.

Review upgrade.log after each database attach to ensure there were no issues upgrading your content dbs.

I would be interested to hear from anyone else who has had this issue, to see if it was a hard edit in the database or an actual issue created by the software and is wider spread.