re-enabling ‘allowing non-owners to invite new users’

snip_20160118134020

One of the things you can control under Sharing settings in the Office 365 SharePoint admin center is Allowing non-owners to invite new users. The default setting is Allowed, and the UI provides us with a link Turn off sharing for non-owners on all sites in this site collection

Clicking this link will change the text of the section to Status: not allowed and Only owners can invite new users

snip_20160118134258

Ok but what if you want to revert this setting? Where is the “enable non-owners to invite new members” link or choice? Right away this looks like it might be a one-way street, but luckily there is a way to re-enable non-owner sharing.

First navigate to the root site of the affected site collection, i.e: https://mytenant.sharepoint.com/sites/mysitecollection

Go to site settings > site permissions > Access Request Settings (in the ribbon) and make sure you check both Allow members to share the site and individual files and folders and Allow members to invite others to the site members group …

ars settings

If you now go back to the SharePoint admin center and check the status of Allowing non-owners to invite new users, you will see the setting is enabled again

How to Create Sandboxed Solutions Without SharePoint Installed Locally

Edit January 22nd 2015: I’ve updated the registry fix to support Visual Studio 2013 (v.12.0.21005.1) and Visual Studio 2015

Sandboxed solutions is a good way to deploy artifacts to any SharePoint site, both on premises and on Office 365. The latest from Microsoft is that only (serverside) code is deprecated in the sandbox, so we’re good to go as far as nocode sandboxed solutions.

Problem

You must have SharePoint 2013 installed in order to create new sandboxed SharePoint projects

Solution

After installing Office Developer tools for Visual Studio and setting creating a string value “SharePoint” = “Installed” under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\SharePoint to “Installed” you will be able to create new sandboxed solutions without actually having to install SharePoint

Here is a .reg file you can download which adds the required value to the registry.

Details

On my current Office 365 project I figured it would be nice to free myself from the constraint of having SharePoint installed locally when creating some simple Sandboxed WSPs. Using Visual Studio 2013 and Office Developer Tools for Visual Studio 2013 – March 2014 Update I saw that i could easily package (publish) existing sandboxed solutions, but I could not add new projects. Since the projects obviously could build, I figured this was a limitation in the project wizard for new SharePoint 2013 projects.

sp-not-installed

I started by investigating the project template for “Empty SharePoint project” which you will find here

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ProjectTemplates\CSharp\Office SharePoint\SPSol\1033\SharePoint15EmptyProject\SharePointEmptyProject.vstemplate

inspecting the template you will find a reference to Microsoft.VisualStudio.SharePoint.ProjectExtensions.Wizards.EmptyProjectWizard. A bit of reflection and detective work later and i found out that the test checks for installed SharePoint version in the following way.

  • Load the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\SharePoint
  • Check if the value equals “Installed”

After adding this key and restarting Visual Studio (as and Administrator, the wizard will do this for you if you forget) I could now add new SharePoint projects.

Its worth noting that you should remove any SharePoint assembly reference after creating a new Sandboxed solution. I also make sure to set “include assembly in package” to false, just to be sure there is no serverside code being included in my sandboxed solution.

Custom Actions and externalized JavaScript

How can I have Custom Actions using custom JavaScript without including the JavaScript on all pages?

In short: create a custom action that fetches an external script and includes it in the page. Let this script file be a self executing anonymous function.

When creating Custom Actions for SharePoint it is very common to deploy two artifacts: one ScriptLink referencing a custom js file and the actual custom action. This will allow you to trigger whatever client side code you want with your Custom Action. A downside of this technique is that your JavaScript is included on all pages where the custom action is installed. This adds to the footprint of your solution and may not always be desirable.

One such scenario where you do not want your custom js included everywhere is for Custom Actions deployed to the Microsoft.SharePoint.SiteSettings location (i.e. settings.aspx). This was the case for me at a recent customer project. I had a list and a requirement to have a custom action deployed to SiteSettings allowing the first item of this list to be opened in a dialog window. Another possible use case is to add a link to SiteSettings that allows an administrator to instrument his site, i.e. imagine that we have a JavaScript file checking for a version number in the property bag and doing “upgrades” to a site or hostweb. We are seeing this technique used more and more these days especially when doing Office 365 development.

So what is the alternative to using a ScriptLink? The answer is simple, we borrow a techique leveraged by bookmarklets for years: we externalize our javascript. The first step is to add an UrlAction with a code snippet that pulls in our external JavaScript file and injects it into the page

 <CustomAction
        Id="OkmsSiteMetadata"
        GroupId="Customization"
        Location="Microsoft.SharePoint.SiteSettings"
        Title="Site Metadata"
        Description="Configure Metadata for this site">
    <UrlAction Url="javascript: (function () { var jsCode = document.createElement('script'); jsCode.setAttribute('src', '/SiteAssets/OkmsSite/js/customaction-okmssite-settings.js'); document.body.appendChild(jsCode); }());" />
 </CustomAction>

Here’s the trick: the external JavaScript will be evaluated once injected into the page. This means if you click your Custom Action twice, the script is injected twice. To mitigate this and to make sure we do not interfere with any of the other script living on the page we wrap all our code in a self executing anonymous function. This means the script is self contained and fire-once and then its gone from the global namespace.

Here is the content of customaction-okmssite-settings.js. This example JavaScript will display the first item of the list in a modal

(function () {
    $.ajax({
        url: "/temarom/1/_api/web/lists/GetByTitle('Name Of My List')/Items",
        type: 'GET',
        headers: { "Accept": "application/json; odata=verbose" },
        success: function (data) {
            SP.SOD.execute('sp.ui.dialog.js', 'SP.UI.ModalDialog.showModalDialog', { url: _spPageContextInfo.webServerRelativeUrl + '/Lists/SiteMetaData/EditForm.aspx?ID=' + results[0].ID, width: 800, height: 600 });
        },
        error: function (XMLHttpRequest, textStatus, errorThrown) {
            console.log('Failed to fetch list. status:' + textStatus + ', error:' + errorThrown);
        }
    });
})();

As mentioned previously this technique can be used to do other tasks, i.e. administrator initiated updates of site artifacts – something that back in the full-trust days was done by feature receivers.

Changing the width of the Site Feed or My Site Newsfeed web part

Something that pops up now and again as a requirement is the ability to make the the My Site News feed or Site Web part fit into a less narrow column then its OOB styles allows. The absolute minimum width requirement for these web parts to work without overriding any styles is about 475px.

the MySite News Feed webpart (also known as the MicroFeedWebPart) alone has roughly 181 related classes in portal.css, with a lot of these specifying a min-width.

The following css will allow you to shoe horn your newsfeed web part into a more narrow column. I’ve also smoke tested this on the site feed web part, and it appeared to have the desired effect for this as well.

/* resetting min-width */
.ms-microfeed-attachmentPreviewDiv,
.ms-microfeed-rootText,
.ms-microfeed-fullMicrofeedDiv,
.ms-microfeed-microblogpart,
.ms-microfeed-feedPart,
.ms-microfeed-rootText,
.ms-microfeed-replyText,
.ms-microfeed-replyArea
{
    min-width: 0; 
}
/* The width of attached images. Ajust to needs */
.ms-microfeed-attachmentImage {
max-width: 260px;
}

An example of how the webpart gracefully shrinks

microfeed

As with all branding of SharePoint try to apply this css only on pages where you need to alter the width of these webparts.

Unexpected error occurred while communicating with Administration Service

One of my clients recently notified me that they got an error when trying to access the FAST Search Keywords, Fast Search site promotion and demotion and FAST search user context under Site settings on their search center.

Site Settings from FAST search center

Apparently this had been working quite flawlessly up until a couple of weeks ago, when suddenly they started seeing the error: Unexpected error occurred while communicating with Administration Service when trying to access e.g. /_layouts/contextualkeywordmanagement.aspx

Error when trying to access the FAST admin pages

A common cause for this error is that the SharePoint app pool account is not in the FASTSearchAdministrators group. In this case however, the app pool was already added. I also tried providing Full Control permissions for the FAST service account to the Fast Search Service Applications, as suggested by Gavin McKay, but the problem was still there.

Create FASTSearchKeywordAdministrators group on FS4SP server

What resolved the issue for me was that i ended up creating the FASTSearchKeywordAdministrators group, which has to be created manually on your Fast Search for SharePoint admin server, and added the app pool account used by the web application. This worked instantly without a need for iisreset or reboot.

SharePoint 2010 crawler indexes items, but they are not searchable

At a recent SharePoint 2010 project I recently encountered the issue of a large number of items being indexed and reported as searchable in the index, but I was unable to recall any of these documents in my queries.

Initially I thought this might be a common access rights issue, since the results are security trimmed. I was however able to verify that I had access to a pretty substantial number of pages. Previously I’ve seen similar issues being solved by something as benign as re-creating the Search Service Application (SSA), but this had no effect now.

Search Status

After monitoring the ULS log on both my app server and front end servers, I noticed this error popping up whenever a query was fired



06/11/2012 11:23:32.93 w3wp.exe (0x1BB0) 0x1054 SharePoint Foundation General 7fdb Unexpected AuthZInitializeContextFromSid failed! c1e2755a-d00c-4855-b6c6-8f42d1c1a1c0

Notice the term AuthZInitializeContextFromSid. A quick search turned up this technet SP2010 forum post

http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/688b5c52-f478-463b-bc00-debfd0c3be2b

Jeremy Thake suggests adding the service account used by the search service to Windows Authorization Access group. We tried this, but unfortunately the problem still persisted.

After some further googling, I found this blog post

http://horsik.wordpress.com/2012/02/28/sharepoint-2010-search-is-not-working-no-results/

Which turned out to solve my issue with just a couple of lines of powershell:

first i executed the follwing powershell

$ssa = Get-SPEnterpriseSearchServiceApplication "search service application"
$ssa.SetProperty("ForceClaimACLs",1)

And then i did a full re-crawl of my content sources.

As mentioned in Horsik’s blog post, KB2344518 describes this issue and apparent root cause.

For completeness i should mention that my customer uses Network Load Balancing (NLB) in front of their front end servers

SharePoint crawler reports Proxy Error during crawl of local sharepoint sites

After introducing Network Load Balancing (NBL) in front of our SharePoint 2010 farm we started seeing the following errors in the ULS logs on our front end servers during crawls of our local sharepoint sites

06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search PHSts dvg4 High ****** Server intranetbeta.mycustomer.com security initialization failed, hr = 80041204 error Message Error from SharePoint site: HttpStatusCode BadGateway The request failed with HTTP status 502: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). ). [sts3util.cxx:1360] d:\office\source\search\native\gather\protocols\sts3\sts3util.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search PHSts dv5x High CSTS3Accessor::InitServer: Initialize STS Helper failed. Return error to caller, hr=80041204 [sts3acc.cxx:1789] d:\office\source\search\native\gather\protocols\sts3\sts3acc.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search PHSts dv3t High CSTS3Accessor::InitURLType fails, Url sts4://intranetbeta.mycustomer.com/siteurl=/siteid={410dbdeb-efc5-485b-9d22-59986dcec73f}/weburl=about/organized/webid={0cead255-92f4-4f6b-8217-8cab8fe0f5ff}/fpfolder=, hr=80041204 [sts3acc.cxx:277] d:\office\source\search\native\gather\protocols\sts3\sts3acc.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search PHSts dvb1 High CSTS3Accessor::Init fails, Url sts4://intranetbeta.mycustomer.com/siteurl=/siteid={410dbdeb-efc5-485b-9d22-59986dcec73f}/weburl=about/organized/webid={0cead255-92f4-4f6b-8217-8cab8fe0f5ff}/fpfolder=, hr=80041204 [sts3handler.cxx:312] d:\office\source\search\native\gather\protocols\sts3\sts3handler.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search PHSts dvb2 High CSTS3Handler::CreateAccessorExD: Return error to caller, hr=80041204 [sts3handler.cxx:330] d:\office\source\search\native\gather\protocols\sts3\sts3handler.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x142C SharePoint Server Search FilterDaemon e4ye High FLTRDMN: Errorinfo is "Error from SharePoint site: HttpStatusCode BadGateway The request failed with HTTP status 502: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). )." [fltrsink.cxx:553] d:\office\source\search\native\mssdmn\fltrsink.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search Indexing fsa0 Monitorable GetVirtualServerPolicy fail. error 2147750404, strStsUrl http://intranetbeta.mycustomer.com
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search PHSts dvt6 High SetSTSErrorInfo ErrorMessage = Error from SharePoint site: HttpStatusCode BadGateway The request failed with HTTP status 502: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). ). hr = 80041204 [sts3util.cxx:5122] d:\office\source\search\native\gather\protocols\sts3\sts3util.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search PHSts dvi3 High ***** Couldn't retrieve server http://intranetbeta.mycustomer.com policy, hr = 80041204 [sts3util.cxx:1765] d:\office\source\search\native\gather\protocols\sts3\sts3util.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search PHSts dvu0 High STS3::StoreCachedError: Object initialization failed. Message: "Error from SharePoint site: HttpStatusCode BadGateway The request failed with HTTP status 502: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). )." HR: 80041204 [sts3util.cxx:5216] d:\office\source\search\native\gather\protocols\sts3\sts3util.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search PHSts dvg4 High ****** Server intranetbeta.mycustomer.com security initialization failed, hr = 80041204 error Message Error from SharePoint site: HttpStatusCode BadGateway The request failed with HTTP status 502: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). ). [sts3util.cxx:1360] d:\office\source\search\native\gather\protocols\sts3\sts3util.cxx
06/08/2012 15:24:08.64 mssdmn.exe (0x04E0) 0x1374 SharePoint Server Search PHSts dv5x High CSTS3Accessor::InitServer: Initialize STS Helper failed. Return error to caller, hr=80041204 [sts3acc.cxx:1789] d:\office\source\search\native\gather\protocols\sts3\sts3acc.cxx

The culprit turned out to be our old friend the Windows Loopback check, which somehow hadn’t bothered us before NLB was enabled. Our solution was to
adding all sites (web applicaitons and alternate access mappings) to BackConnectionHostNames in the registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Alternatively you can disable the loopback check all together, this is however not advisable for production environments as doing this will make your servers more vulnerable.

more info on the loopback check here
http://support.microsoft.com/kb/926642

Google Talk and MSN cannot connect when using Pidgin

Since I don’t want 4+ IM clients running at any one time (actually 5 if I run MSN in multiple instances) I’m pretty much depending on Piding as my “one IM app to rule them all”. One nuisance I’ve often faced is that the out of the box Protocol configurations of pidgin is unable to connect to Google Talk and MSN when behind a firewall. Here’s my solution (something that works for me at least)

Google Talk

Most common problem for me is that Google talk is unable to connect. The setting that worked for me was to basically change connect port to 433 and connection security to old style ssl
image
image

MSN

For MSN I just checked the “Use HTTP Method” and I was good to go
image

Edit (November 21st 2011):

The MSN http method stopped working for me when behind a proxy. After some googling i found this Pidgin plugin which actually does work when using “http method” : http://code.google.com/p/msn-pecan