.NET FOLLOWER

    If you get the exception shown below, you likely need to increase the List View Lookup Threshold.

[ArgumentException: Value does not fall within the expected range.]
   Microsoft.SharePoint.SPFieldMap.GetColumnNumber(String strFieldName, Boolean bThrow) +23672719
   Microsoft.SharePoint.SPListItemCollection.GetColumnNumber(String groupName, Boolean bThrowException) +174
   Microsoft.SharePoint.SPListItemCollection.GetRawValue(String fieldname, Int32 iIndex, Boolean bThrow) +44
   Microsoft.SharePoint.SPListItem.GetValue(SPField fld, Int32 columnNumber, Boolean bRaw, Boolean bThrowException) +26792787
   Microsoft.SharePoint.SPListItem.GetValue(String strName, Boolean bThrowException) +77
   Microsoft.SharePoint.SPListItem.get_Item(String fieldName) +12
   ...

Go to Central Administration, click on Application Management, then click on Manage web applications, select an application throwing the exception (in my case it’s SharePoint – 80), in the upper Ribbon click on arrow below the General Settings group to display a drop-down menu, click on Resource Throttling.

Increase a value of the List View Lookup Threshold. The default value is 8. I set to 20, and the exception is gone.

    In SharePoint 2010 a BDC model can be easily deployed using PowerShell. Launch SharePoint 2010 Management Shell (click on Start, then All Programs -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell) and execute the following script:

$metaStore = Get-SPBusinessDataCatalogMetadataObject 
                -BdcObjectType "Catalog" -ServiceContext "http://yourWebAppUrl"
Import-SPBusinessDataCatalogModel 
                -Path "c:\folder\subfolder\yourfile.bdcm" -Identity $metaStore -Force

Note: here command line parameters are wrapped to the next lines for readability only. In SharePoint 2010 Management Shell, each command and its parameters should be in the same line.

The first command, Get-SPBusinessDataCatalogMetadataObject, returns and saves in the $metaStore variable a Catalog metadata object relevant to your web application accessible through the url http://yourWebAppUrl. The second command, Import-SPBusinessDataCatalogModel, imports a Business Data Connectivity Model defined in a file, path of which is indicated by the -Path key. The model is to be added to the Catalog referenced by the $metaStore and overwrites the existent version (if any) due to the -Force key.

Despite the -Force key you can get the following error:

Error: Cannot merge contents of LobSystem (External System) with Name 'Products' 
as it appears to be different from a preexisting LobSystem in the current load context.

What you need to do in this case is remove the previous version of the model.

    Our production SharePoint Farm and customer users are deployed in one domain, let’s call it Root, while the development and quality control farms are in a child domain, let’s name it Child.Root. The Child.Root domain trust to the parent Root domain, while the Root domain knows nothing about the Child.Root. So, we have a one way trust domains configuration where the Child.Root trusts Root, but not vice versa. Under such conditions we have faced the issue with SharePoint Search when an user from the trusted parent Root domain gets zero results, executing a search query on the Child.Root.

The solution was borrowed from the Microsoft Knowledge Base Article – Unable to Perform a query on a One-Way trust Domains Scenario when an User from the trusted domain performs the query and the SSA Application Pool account is from the Trustee Domain. The topology described in the KB article presumes that domains with a one way trust relationship are in two separate forests. Despite the fact that in our case both domains are in one forest, the solution works great, though.

So, you need to follow these steps:

1. Launch SharePoint 2010 Management Shell (click on Start, then All Programs -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell);
2. Type $searchapp = Get-SPEnterpriseSearchServiceApplication and press Enter;
3. Type $searchapp.SetProperty(“ForceClaimACLs”,1) and press Enter. Don’t wait for any confirmation, you won’t see it;
   
4. Restart a full crawl through Central Administration (click on Start, then All Programs -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Central Administration, then go to Application Management -> Manage Service Applications -> Search Service Application, then in Crawling section click on Content Sources, open context menu for the Content Source you want to re-crawl, for example, Local SharePoint sites and click Start Full Crawl);
   

After the SetProperty() command has set value of the ForceClaimACLs parameter in the search administration database to 1, ACLs are stored as Claims instead of NT tokens. Note, however, that you needn’t switch other SharePoint applications (different from the Search Service Application) to Claims based authentication. Also, keep in mind that this is a one-way change, so you won’t be able to reverse it back to classic mode.

After the full crawl is performed, users see search results, regardless from which domain they are logged in.

    In our SharePoint applications we actively use writing into Application Event Log. After adding a new Windows 2008 Server R2 machine to our SP 2010 farm, we was getting the exception “System.ComponentModel.Win32Exception: Access is denied” with the description “Cannot open log for source {*}. You may not have write access.” Apparently, the given error is caused by writing to log when it’s called under an ordinary user with limited rights, who, however, can view web pages. I tried to provide Authenticated Users group with Full Control to the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog] registry key, with no success though.

The workaround is add or modify the magic CustomSD value under the registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application]. So,

1. Open Registry Editor (click Start, then Run, then type regedit and click Ok);
2. Locate the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application] key in the registry tree;
3. If the CustomSD value doesn’t exist, create it (right click on Application key, then click New -> String Value and set CustomSD name). Then set value data to O:BAG:SYD:(A;;0x3;;;AU) (right click on CustomSD, then click Modify, type the O:BAG:SYD:(A;;0x3;;;AU) and click Ok). The result should look as shown on the picture below:
   
4. If the CustomSD value already exists, append (A;;0x3;;;AU) to the value data (right click on CustomSD, then click Modify, type the (A;;0x3;;;AU) at the end of value data and click Ok). After appending, the resultant value data would be similar to:

   O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0x f0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;AU)

The CustomSD registry value describes which accounts have the read/write/clear permissions to Application Event Log. The format of the value data corresponds to Security Descriptor Definition Language (SDDL), so (A;;0x3;;;AU) consists of

• A – SDDL_ACCESS_ALLOWED or ACCESS_ALLOWED_ACE_TYPE, one of ACE types;
• 0x3 – ELF_LOGFILE_WRITE (0x2) & ELF_LOGFILE_READ (0x1), the access rights to the EventLog;
• AU – Authenticated Users group;

It looks funny that direct giving permissions for Authenticated Users group haven’t had effect, while the EventLog‘s security is controlled by the CustomSD registry value.

Update: If a web application supports anonymous access, you’d better replace AU in (A;;0x3;;;AU) with WD, where WD is Everyone or a group that includes all users. So, the final version in this case is (A;;0x3;;;WD).

Related posts:

• SharePoint: Simple Event Logger

    The SharePoint is based on ASP.Net, so all possible ASP.Net errors may easily become apparent in a SharePoint application. The ‘Code blocks are not allowed in this file‘ issue isn’t an exception. To get rid of it we need to enable server side scripts by modifying the web.config file. Specifically we need to locate <PageParserPaths> within web.config and add a proper <PageParserPath> node to it. The following example demonstrates how to allow server side scripts for all pages, which contain the apps virtual folder in their relative paths:

<PageParserPaths>
    <PageParserPath VirtualPath="/apps/*" CompilationMode="Always" 
              AllowServerSideScript="true" IncludeSubFolders="true" />
</PageParserPaths>

After the modification, server side scripts will work for such pages as e.g.

http://myServer/apps/default.aspx
http://myServer/apps/appsubfolder1/MyPage.aspx (*)
http://myServer/apps/appsubfolder2/MyPage.aspx (*)
http://myServer/apps/appsubfolder2/subfolder3/MyPage.aspx (*)
and so on. 

Note that pages urls marked with asterisks (*) are eligible only if IncludeSubFolders is set to true.

To enable server side scripts for certain page, use something like this:

<PageParserPath VirtualPath="/apps/appsubfolder2/subfolder3/MyPage.aspx" 
              CompilationMode="Always" AllowServerSideScript="true" />