sharepoint – Łukasz Karolak

Failed to query the OAuth S2S metadata endpoint

Upon registration of workflow service in SharePoint 2013, running the following command in SP Management Shell:
[powershell]Register-SPWorkflowService -SPSite http://testsite/sites/workflow1 -WorkflowHostUri https://testsite:12290[/powershell]
the following error is displayed:

Register-SPWorkflowService : Failed to query the OAuth S2S metadata endpoint at URI http://testsite/sites/workflow1/_layouts/15/metadata/json/1 .

Error details: 'The metadata endpoint responded with an error. HTTP status code: Forbidden.

It seems that the permissions are missing (403). However, if you open the indicated JSON URL with IE logged in as admin, you get the expected result.

In order to resolve this issue:
1. go to Central Administration
2. Manage Service Applications
3. Select the Workflow Service Application
4. In the ribbon bar, click on „Administators”, add tha Farm Admin and grant him full control.

Re-run the shell command, it should now run smoothly without error.

Hope this helps,
Łukasz

Login prompt when opening Office documents from a public SharePoint site

Hi there,

we have a following scenario:

a MOSS 2007 web application,
publicly accessible,
its URL added in Internet Explorer to the intranet sites,
checked in and published office documents within this site.

The problem occurring is that when one wants to open a MS Office document from the site using Internet Explorer, the Office application (Word, Excel..) is asking for username and password, although the document is publicly visible and not password-protected. Even if one clicks „Cancel” on the login prompt, the file is opened seamlessly.

After some research, I came across two possible solutions that can be applied in order to get rid of the unnecessary login prompt: either remove the URL from IE’s intranet sites list (which might not be desired because of other benefits of intranet sites), or make following changes in the applications settings in IIS (7):

Go to the web site’s features, open the request filtering feature, and in the „HTTP Verbs” tab, add a deny rule for the verbs „OPTIONS” and „PROPFIND„. In my case, the use of checking in/out documents, opening them in read-only mode etc., was not necessary in this application, thus the verbs could be inhibited without the loss of other needed functionalities.

More information can be found in this KB article.

Hope this helps,
Lukasz

MOSS Search web service – impersonation problems when calling from an external application

Hi there,

A while ago I was implementing a search functionality within an ASP.NET application. The plan was to use the SharePoint Search for crawling and indexing the contents, and afterwards, from my application, connect to the MOSS web service and perform the needed query upon it.

I had some web sites and BDC applications prepared within a scope; everything crawled and indexed – so far so good.

In the ASP.NET application, the service reference to the exposed asmx has been added (e.g. http://sharepoint/_vti_bin/search.asmx ).
Then I tried to invoke the service sending a query packet xml object:
[csharp]QueryServiceSoapClient client = new QueryServiceSoapClient();

client.Query ("<QueryPacket>….");[/csharp]
At this stage, the following exception occurred:

Error:
Retrieving the COM class factory for component with {CLSID BDEADEE2-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 80070542

It doesn’t say much, does it? After some reading, it came out that the app could not authenticate itself against the MOSS webservice in a correct manner – the credentials for the webservice weren’t passed as one would expect.
Of course, an explicit assignment of username and password was not the way I wanted to go. I needed the application pool account (which had all needed permissions on the webervice) to be used and impersonated on every call to the asmx.

Changing the client’s impersonation level to 'Delegation’ solved the issue:
[csharp]client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Delegation;[/csharp]
Exception gone, search results present.
Hope this helps,
Łukasz

SharePoint: „Loading this assembly would produce a different grant set from other instances” after a security patch from MS

Hello,

after installing the critical patches for .NET framework, as described in the MS Security Bulletin MS11-100, some of our MOSS 2007 applications were hitting the following exception:

FileLoadException : Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401

It seems that the security fix applied in the patch KB2657424 (maybe also KB2656351, although it’s a different version of .NET framework) has caused this temporary problem. The solution is to recycle the affected applications’ IIS pool – the exceptions don’t occur anymore and applications work correctly again.
The solution with restarting application pools appears to be quite strange, since the whole machine had to be restarted upon installation of those security updates. But still, it worked.

Hope this helps,
Łukasz

SharePoint: backup failed – the current operation timed-out after 3600 seconds

Hi,

A short though maybe a helpful one:

Symptoms:
1. MOSS 2007 central administration states: backup failed. One or more databases weren’t properly backed up.
2. Backup logs contain following message:

Error: Object Shared Search Index failed in event OnPrepareBackup. For more information, see the error log located in the backup directory.
WebException: The current operation timed-out after 3600 seconds

3. Similar message (timeout) regarding the SSP’s database.
4. SSP administration page indicates one or more apparent endless crawls running, on content sources which are rather small.

Resolution:
1. Restart the Office SharePoint Search service.
2. Clear search index – reset crawled content in SSP’s search administration.
3. Start full crawls on your content sources.

Best,
Łukasz

Posted from WordPress for Android

SharePoint: deleting a SSP leaves a running SQL agent job

Hello,

On one of MS SQL Server database backend machines, I was getting a lot of windows event log entries stating that there was a problem for our SQL Server account with accessing one of the databases:

Login failed for user 'DOMAINsqluser’. Reason: Failed to open the explicitly specified database. [CLIENT: x.x.x.x]

Investigating the corresponding SQL Server instance logs, further details of the issue followed:

[298] SQLServer Error: 18456, Login failed for user 'DOMAINsqluser’. [SQLSTATE 28000]

[298] SQLServer Error: 4060, Cannot open database "SSP_XYZ" requested by the login. The login failed. [SQLSTATE 42000]

First idea was of course checking the permissions of the user within that database, but then there came the weird thing – a database with such name did not exist. Another approach was that maybe some old web application has been forgotten and still uses explicitly the DB name (e.g. in web.config). Not the cause either.

Finally, since the database name contained ‘SSP’, it had most probably something to do with a Shared Services Provider database. The current one we have has a different name, so the name occurring in the error logs referred to a non-existing SSP. We were able to find out that such SSP has been created and deleted a while ago. The corresponding database has been also removed from the SQL-Server, but one oddment remained there: a SQL Agent job for deleting expired sessions. The agent tried to connect to that DB every minute, and encountered the error mentioned above.

You can find the jobs either directly in the table ‘msdb.dbo.sysjobs’, or within the object explorer, under the “SQL Server Agent” node:

Deleting or disabling the job responsible for connecting to the non-existing SSP’s database solves the problem.

Hope this helps,
Łukasz

“The specified address was excluded from the index”

Hello,

an issue that occurred recently was that a content source within our SSP for search (MOSS 2007) did not include any items. The crawl log of the SharePoint’s Central Administration stated the following:

The specified address was excluded from the index. The crawl rules may have to be modified to include this address. (The item was deleted because it was either not found or the crawler was denied access to it.)

Interestingly, some of the content sources we already had before were crawled without any obstacles, thus the (mis)configuration of the problematic application seemed suspicious. After checking the permissions of service accounts involved in the crawling process (not the cause), and after comparing the settings between the apps (not the cause as well) – the problem was in the crawl rules set up for this content source. The option for crawling complex URLs hasn’t been activated for the subdomain URL we wanted to crawl. Enabling the “Crawl complex URLs (URLs that contain a question mark (?))” option under Shared Services Administration: SSP > Search Administration > Crawl rules > Add or Edit Crawl Rule and starting the full crawl from the beginning solves the problem.

But still the question was, why the non-complex, normal URLs could not be crawled by the service. The cause was in our IIS configuration, which is globally set up to automatically detect cookie mode for session state. This results in appending a query string parameter to the URL at first request. So that the URL looks similar to this: http://www.ourdomain.com/index.html?AspxAutoDetectCookieSupport=1 .

Now it seems pretty clear why the crawler without the rule mentioned before had problems. It failed at the first request to the root URL, since the rule has not been met. Hence, it could not continue crawling and left the index empty with the error/warning message.

Hope this helps,
Łukasz

SharePoint: access denied when trying to copy a list (item)

Hey there,

Lately, while trying to copy a SharePoint list from one site to another (or later also single list items), I got this infamous “Access denied” SharePoint error. At first of course the idea is to log in as a super-user. But when this operation failed also with the account of Site Collection Admin and/or Site Owner role, it seemed less trivial than just a missing permission within the site collection.

Unfortunately, a quick jump into the SharePoint logs didn’t bring me much further:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Since this problem has occurred in more than one application on our SharePoint server, I was assuming it to be a global misconfiguration. Hence, had to check out the Central Administration. There was the solution:

In Central Administration > Operations > Service Accounts I checked which account actually is responsible for the communication with Windows SharePoint Services on our server. So, in the Web application pool section, I selected the WSS Web application and the application pool of the application which was giving me this “Access denied” message.

The account was the predefined one – the Network Service.

There’s the rub! Since we’re using own domain accounts for such cases and only they’re enabled to access the WSS, the Network Service account was actually getting the “Access denied” message (when trying to connect to one of the SharePoint Web Services).

Changing the account from predefined one to the configurable one with our username and password did the trick. I just had to do an iisreset after this change.

Probably this solution also fixes some other problems we might have encountered, where the communication between application and WSS would fail.

Hope this helps,
Łukasz

„The site collection could not be restored”

Hi there,

Recently while performing standard site collection backup from production environment and restoring it onto test environment (MOSS 2007), we ran across a following problem. The stsadm restore command failed after several minutes with the message:

„The site collection could not be restored. Please make sure the content databases are available and have sufficient free space”

Ok, so the first suspect has to be disk space. According to the MS knowledgebase article, one should ensure that the DB has not any maximum size set and that the drive where WSS works has enough space. After freeing up some additional space both on WSS drive as well as on the DB drive, the amount of free space in each location was almost 3 times bigger than the size of the backup file we wanted to restore. But the error message appeared again.

Further attempts based on some other blog posts (like restarting the sharepoint timer service or doing an iisreset) did not work in our case. Comparing the exact versions of WSS and system patches of both environments brought the same results on both sides, so incompatibility was not the issue.

What actually did work in the end was removing content database and adding a new one in Central Administration:

1. Application Management > Content databases > click the existing one, then check the option „remove content database” and confirm.
2. Add a new content database > settings can stay as they were with the old one, just choose different name from the previous one.
3. Run once again stsadm -o restore…. operation successful!

Interestingly, we didn’t physically delete the old DB’s data files until the restore succeeded. Thus, while executing the command, the system had even less space than before, but made it anyway.

Hope this helps,
Łukasz

Exposing SharePoint calendars for iCalendar clients

Hello there,

since Sharepoint offers out-of-the-box calendar and scheduling capabilities, it is a nice option for teams in terms of improved collaboration and sharing common agendas. By default, users can access the MOSS calendars using a browser or by syncing it with their Microsoft Outlook clients. Additionally, a RSS subscription is also available.
So far, so good, but if we need to subscribe to the calendar using a Mac or an iPhone, iPad, or any other client supporting the iCalendar specification, we have to use a custom solution.

Simply put, a file with the content type text/calendar needs to be generated, and it has to more or less comply with the RFC 2445 specification. Of course you may want to implement it your way from scratch, but there’s a nice iCal Exporter kit from CodePlex. It has been developed as a MOSS feature, but you can easily adapt it to serve users in a different way, for example as a custom http handler. So one can create a class inheriting the IHttpHandler interface, deploy the class library onto the Sharepoint application, and register the handler in web.config:

<add verb="GET,POST" path="*/ical.ics" type="MyLibrary.MyIcalHandler" />

Then we could access the generated file for example via http://myhost/mysite/lists/calendar/ical.ics , and subscribe to the calendar in a corresponding client software. In the handler itself, based on the request URL, we can fetch the corresponding Sharepoint list, iterate through its items and generate the proper entries, then flush it to the browser. The iCal Exporter kit also deals with recurring calendar entries, deleted event series’ occurences, all-day events, so that almost every case is covered.

One thing worth mentioning: when generating an event entry, be careful using the DTSTAMP property. In order for iCal clients to properly recognize changes made to calendar entries, one has to assign the last-modified-date property of the corresponding SPListItem as DTSTAMP value:

 foreach (SPListItem item in calendarList.Items)
 {
    // write vevent start...
    DateTime modified = Convert.ToDateTime(item["Modified"]);
    String dtstamp = "DTSTAMP:" + modified.ToString("yyyyMMddTHHmmssZ");
    // write dtstamp, other properties, vevent end
 }

Otherwise you may encounter a problem that the client won’t fetch a calendar entry’s changes.

Hope this helps,
Łukasz