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.

User Profile Replication Engine gets stuck Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed.

For the past 4 weeks I have had a ticket open with Microsoft about the user profile replication engine getting stuck on a particular user. The following errors were logged in the event log:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed.

   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)

   at Microsoft.KNG.ReplicationEngine.Helper.UserProfileWebService.UserProfileService.GetUserProfileByIndex(Int32 index)

   at Microsoft.KNG.ReplicationEngine.Helper.ReplicationEngineManagerFull.ReplicateProfile()22/03/2011 10:07

This continued to get logged in the event log until an entry was logged about event log flooding.

OK so the scenario.

I wanted to replicate all user profiles in Farm A in SSP 1, to Farm B in SSP 2.

After running a full profile replication, the list of replicated profiles stopped at the same user every time and the above errors were logged.

I eventually tried incrementing the 'StartingProfileIndex' by 1 number and kicking off the replication again, this was then successful for all remaining users.

So then I knew I had an issue with ProfileIndex numbers between 1740 and 1743 (the next sucessful profile).

If you check in C:\Program Files\Microsoft\SPAdminToolkit\ and look for Err_Full_Profile_Index_Pull_xxxxxxx this is a log file and will give you the number of the problem profile

I looked at the SSP database, and expanded the table 'dbo.UserProfile_Full', I then did a select for all records.

The column we are interested in is called 'RecordID', so naturually I looked for the RecordID that wouldn't replicate.

There is a red herring here, because the username next to each number did not correspond to the view in the replication engine. Because the replication engine labels the first user as 0, it then labels the 2nd user with the 'RecordID' of the first user, and so on so forth.

So for my faulty user, I need to find the 'RecordID' then look at the next 'RecordID' in the table, and that is the problem profile.

I then checked with the user that their profile didn't have anything too important in it, they weren't using any My Links etc and had no files in their My Site.

I then went ahead and deleted their profile from the 'View User Profiles' in the SSP Admin site.

I then did a full profile import, to get her a fresh user profile in the SSP database.

After doing this, the replication engine did a successful full import of all user profiles - problem solved!

I hope this saves someone some time, as I spent many hours on the phone to MS about this and they were extremely unhelpful.

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