• Environment: Windows 2008 SP2, SharePoint 2010 October CU, SQL Server 2008 SP2

• PDF files were hosted within SharePoint
• Adobe PDF ifilter were installed correctly

Requirement

SharePoint search should be able to search within PDF content

 Issue

After numerous checks and cross checked (by multiple people), Search was just not be able to crawl PDF content.

Regarding installing Adobe PDF iFilter, there are multiple documentation on the internet, but I was primarily going off https://support.microsoft.com/kb/2293357

Weird thing was everything was working per documentation in development (single) server environment, but just would not work in QA (multi) server environment.

After painstaking review of ULS (with verbose turned on for SharePoint Search), ULS had listed below entry

 05/15/2012
12:58:50.58        mssdmn.exe (0x13C0)        0x063C        SharePoint Server Search        Exceptions        1hjo        Medium        Exception thrown: 0x80070005 (d:\office\source\search\native\ytrip\tripoli\filtereg\filtreghelper.cxx:788 ip 0x000007FEE19E2D59)

 Above error was detected everytime an attempt was made to request PDF file.

 For e.g.

 CHttpAccessorHelper::InitRequestInternal - successful request for 'https://servername/Shared%20Documents/PDF%20Search%20Text%20Sample.pdf'.  [httpacchelper.cxx:613]  d:\office\source\search\native\gather\protocols\http\httpacchelper.cxx

 Resolution

Exception 0x80070005 is related to Access denied, hence this pointed to the fact that service account running SharePoint Search (for e.g. Domain\svc_SPS_Search) did not have access to PDF Filter file used by Adobe.

In dev env, it worked as everything was running under farm account).

 After giving appropriate READ permissions to Adobe Filter binary folder (and restarting Search service), we were able to crawl PDF files hosted within SharePoint

 Note: This issue may also occur for FoxIT on multi server environment (with Search service account being different from farm account).

For e.g.
if Idp (ADFS, SiteMinder, RSA FIM) uses AD LDS or AD, then in most environments, we would want to reuse the AD security groups for authorization
within SharePoint.

SharePoint 2010 will handle multi-valued claims depending upon how it gets multi-value claimed from Idp.

For e.g. if SAML payload from Idp (for e.g. ADFS, SiteMinder, RSA FIM etc) is in the format listed below, then SharePoint will treat claim value "Value1, Value2" as one claim

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AttributeNamespace="https://schemas.xmlsoap.org/claims" AttributeName="groups">

<saml:AttributeValue>Value1, Value2</saml:AttributeValue>

</saml:Attribute>

To treat multi-values claims as separate claims, SharePoint needs to get multi valued SAML payload either as

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AttributeNamespace="https://schemas.xmlsoap.org/claims" AttributeName="groups">

<saml:AttributeValue>Value1</saml:AttributeValue>

<saml:AttributeValue>Value2</saml:AttributeValue>

</saml:Attribute>

or

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AttributeNamespace="https://schemas.xmlsoap.org/claims" AttributeName="groups">

<saml:AttributeValue>Value1</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AttributeNamespace="https://schemas.xmlsoap.org/claims" AttributeName="groups">

<saml:AttributeValue>Value2</saml:AttributeValue>

</saml:Attribute>

For above SAML payload, SharePoint will convert above incoming multi-valued claims into individual claims (within SharePoint)

For e.g.

SharePoint Claims Web Part

Hope this helps

Background

• On number of occasions there arises a need to capture HTTP traffic. In dev environments, this is usually accomplished using tools like NetMon or Wireshark
• Issue arises when we have a need to capture HTTP traffic which is enabled with SSL
• Without the ability to capture SSL traffic, one usually has to disable SSL, capture traffic and then enable SSL

Requirement

• Capture SSL HTTP traffic via Wireshark utility
• Have access/required permissions to export out specific certificate in question

Disclaimer

These steps should not be performed in production environment and are provided as potential options for debugging purposes in  development environments which have SSL enabled HTTP traffic.

Steps

Note: Listed below steps need to be done on Server presenting the certificate

1. Export out the SSL certificate (with password) using MMC snap in. This needs to be done on the server which is presenting the SSL certificate.

2. Open wireshark
3. Go to Edit/Preference, select "SSL" as protocol
4. Enter appropriate info: X.Y.Z.A (ipaddress),443,http,C:\Users\Login\Desktop\Cert.pfx,(password)
   1. X.Y.Z.A is the IP address of the HTTP server or load balancer in front of the HTTP server
   2. 443 is the SSL port used
   3. Http is the protocol used
   4. "C:\Users\Login\Desktop\Cert.pfx" is the location of the certificate file that contains the certificate (w.r.t to wireshark utility)
   5. Password used while exporting the certificate in step 1 above.

5. Click ok
6. Close Wireshark
7. Open wireshark and and start network capture

8. You should be able to see SSL enabled HTTP traffic

Background

• On number of occasions, when using claims authentication, Trusted provider bases its authentication on Active Directory LDS.

• In these cases, profile  data from LDS needs to be imported into SharePoint

Design

SharePoint 2010 supports synchronization , offers mechanism to integrate with different directory services like Active Directory Domain Services, SunOne, Novell directory etc. But out of the box there is no support for synchronizing user profiles with Active Directory Light Directory Services (AD LDS). Hence in scenarios where it is necessary to synchronize with AD LDS, it is recommended to make use of LDIFDE utility (available with Windows 2008 server OS) to extract the profile attributes into flat file and then follow the process as documented in Configure profile synchronization using a Lightweight Directory Interchange Format (LDIF) file (SharePoint Server 2010) - https://technet.microsoft.com/en-us/library/ff959234.aspx

Integration Design and Process

Listed below are the high level details associated with the profile synchronization process

Potential Issue

• Once imported,  these profiles need to be linked up with individual users logging into SharePoint using configured Tursted Identity Provider. If this link is absent, then SharePoint ends up creating another profile based on data of the logged user (this contains nothing but the account name)

Requirement

• One profile per user should exist in SharePoint (not multiple)

Resolution

• My colleague Bryan Porter is the one who pointed me to the solution (noted in his blog https://blogs.msdn.com/b/brporter/archive/2010/07/19/trusted-identity-providers-amp-user-profile-synchronization.aspx). This blog talks about how to link profile data coming from Active Directory.
• For linking profiles coming from LDS, listed below are the values which need to be hard coded in ForeFront Identity Manager.

Background

• Client has Load balancer which needs to perform health checks on port 80 to verify if SharePoint is serving pages on Port 80 or not. It not, then it needs to drop traffic to the specific WFE.
• SharePoint is protected by SiteMinder. Normal user traffic gets redirected with 302 to custom SiteMinder form to enter SiteMinder userid and password.
• Per SiteMinder requirement, authentication on specific port is set to Anonymous and ASP.Net only (specifically not set to Windows Auth).
• Load balancer (LB) being used for load balancing purposes but this LB could not handle re-direction.

Requirement

• LB needs to run a health check script to periodically check if SharePoint is serving pages through Port 80. This application is/can also extended on another port using Windows Auth, but the requirement is verify if SharePoint is serving pages on Port 80 (not on the extended port).

Issues

• As port 80 is controlled by SiteMinder, Health Check script cannot run against SharePoint 80 (due to re-direction) and verifying against extended port  does not validate if SharePoint is serving pages through Port 80 or not.

Resolution

Credits go to Henry Winkler (a colleague of mine) for pointing me towards Anonymous option solution

Resolution was to turn on “Enable Anonymous Access” on the Central Administration/Application Management/Authentication Providers/Edit Authentication page for specific web application (Note: do not touch the authentication type).

Once enabled, perform steps listed below to enable anonymous access in the site.

• Return to your sites home page and navigate to the site settings page. In MOSS, this is under Site Actions – Site Settings – Modify All Site Settings. In WSS it’s under Site Actions – Site Settings.
• Under the “Users and Permissions” section click on “Advanced permissions”
• On the “Settings” drop down menu (on the toolbar) select “Anonymous Access”
• Select the option you want anonymous users to have (documents and lists only)

• Create a new doc lib called “HealthCheck” and put in the html page that will be tested.
• Change permissions of the doc lib to stop inheriting from parent
• Under Setting option (this will show up only after one stops inheriting security from the parent), click on “Anonymous Action”, and give View rights to the doc lib.

Within SiteMinder, a new rule will need to be created to allow uncontrolled access to the newly created doc lib and html page (for e.g. https://portal.mycompany.com/HealthCheck*). This will allow unrestricted access to anything under Healthcheck path.

This will allow the script run from LB to check if SharePoint is running under specific port or not.

• Windows 2008 R2, Windows 2008

Issue

On Windows 2008 R2, when one

• Navigates to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
• Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
• Edit Launch and Activate Permissions is disabled

Resolution

After raking my brain on this issue (and searching) I finally came across the cause and resolution here

https://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx

I am documenting this so others do not have to spend hours trying to resolve (and search) this issue and some of you can get to this issue faster using correct keywords (hopefully)

• SQL backend, SSRS server: SQL 2008 SP1
• SQL backend is behind the firewall with only specific DB port open (port used by SQL browser is not open…hence the need to specify specific port)
• RS service login has DB Creator and Security Admin privileges

Issue

During initial configuring SSRS (in creating RS database) we kept getting (during 'generating Rights script' step)

System.Net.Sockets.SocketException: No such host is known

   at System.Net.Dns.GetAddrInfo(String name)

   at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)

   at System.Net.Dns.GetHostEntry(String hostNameOrAddress)

   at ReportServicesConfigUI.RSDatabase.IsLocalDbServer(String dbServer)

   at ReportServicesConfigUI.RSDatabase.GrantRSConnectionRights()

   at ReportServicesConfigUI.RSDatabase.CreateNewDatabase()

RS database does get created but is in incomplete state.

Per https://blogs.msdn.com/psssql/archive/2009/03/05/socketexception-when-creating-a-new-report-server-database.aspx specifying port will not work.

This has been verified (that it does not work) by using SQL alias (which references port) as well as specifying it within "server name,port\SQL Instance" name format (for e.g. SQL_Server,1234\SQL_Instance…port used by SQL instance is 1234)

Using without port references works (for e.g. SQL_Server\SQL_Instance format)…but for this to work,SQL Browser service needs to be enabled and UDP 1434 port needs to be opened through the firewall (if one exists)

Using format SQL_Server\SQL_Instance format works as long as SQL Browser service is running and in case of firewall the SQL Browser port is open (which is not always the case)

Btw, little more digging we did find a workaround….

It seems if you use a connection format like “ServerName\InstanceName,Port”, then SSRS Configuration manager is able to connect without requiring the SQL Browser service.

Without SQL Browser service running (either shutdown or blocked behind the firewall), SSRS Configuration Manager still does not work with “ServerName,Port\InstanceName” format or via SQL Aliases.

Performance Point Server 2007

Performance Point Server 2007 SP2

SQL Server 2008

Environment

Performance Point Server 2007

Issue

After installing monitoring server on a server (without issues and all pre-requisites installed) and running Dashboard design etc, while connecting to performance point server for managing permissions(using Options), kept getting "Unable to connect to server" message.

Within the events log on the server, listed below events were logged.

Event code: 3008

Event message: A configuration error has occurred.

Event time: 6/2/2009 11:13:49 AM

Event time (UTC): 6/2/2009 5:13:49 PM

Event ID: 1bde680dd7bd42ff9441ff6423ac8fcd

Event sequence: 1

Event occurrence: 1

Event detail code: 0

Application information:

    Application domain: /LM/W3SVC/986432534/Root/WebService-4-128884364298709719

    Trust level: Full

    Application Virtual Path: /WebService

    Application Path: D:\Program Files\Microsoft Office PerformancePoint Server\3.0\Monitoring\PPSMonitoring_1\WebService\

    Machine name: PerfPointServer

Process information:

    Process ID: 3412

    Process name: w3wp.exe

    Account name: domain\lsvc-perfpoint

Exception information:

    Exception type: HttpException

    Exception message: Could not load file or assembly 'System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (D:\Program Files\Microsoft Office PerformancePoint Server\3.0\Monitoring\PPSMonitoring_1\WebService\web.config line 25)

Request information:

    Request URL: https://Server:40000/WebService/PmService.asmx

    Request path: /WebService/PmService.asmx

    User host address: 10.237.214.235

    User: 

    Is authenticated: False

    Authentication Type: 

    Thread account name: Domain\lsvc-perfpoint

Thread information:

    Thread ID: 1

    Thread account name: Domain\lsvc-perfpoint

    Is impersonating: False

    Stack trace:    at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

   at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()

   at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

Custom event details:

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.

Analysis

The issue was related to reference to System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 which was missing in the GAC. System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 was present, but the version 1.0.61025.0 was missing.

This was true even thought within the configuration of monitoring server it explicitly stated that ASP.NET 2.0 AJAX 1.0 was installed.

Resolution

This issue was resolved by installing ASP.NET 2.0 AJAX 1.0, which in turn installed the missing System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 in the GAC.

Note: Within the configuration of monitoring server it explicitly stated that ASP.NET 2.0 AJAX 1.0 was installed originally.

Microsoft Office SharePoint Server 2007

SQL Server 2008

Environment

1. WFE (Query)
2. IJS (Index)
3. SQL Server

Issue

Out of nowhere,  we found that indexes were not getting propagated to our Query server.

Within ULS logs, we would see messages like "Query Server(s) not ready".

Within Central Admin, we would see messages like "Waiting on Initialization (XXX) (on Search Admin screen) and "Propagating to Query Server" (on Search Status screen).

Search propagation would be stuck in this state for ever.

No amount of restarting or recreating SSP would solve the issue.

Resolution

Turns out that “Windows SharePoint Administration Service” was not started on Query server. Once re-started indexes started getting propagated to the Query server.

Project Server 2007 (SP1, Infrastructure Update)

Portfolio Server 2007

MOSS(SP1, Infrastructure Update)

Issues

Kept getting "Authentication data undefined for specified Project Server and current user" message when trying to Synchronize Resource Pools within Portfolio Server 2007

Resolution

This is usually due to listed below 3 causes