"Connect to Outlook" Disabled - SharePoint 2013

As mentioned in my last article, we have been recently migrated to SharePoint 2013, users are still reporting issues and today’s article is one of those issue.

Machine configuration entities where the issue has been reported:

OS: Windows 7, 32-Bit.

IE (Internet Explorer): IE9, 32-bit.

SharePoint 2013

Office 2013

Site permissions: Site collection administrator.

Problem description:

Not able to connect CALENDAR list to Outlook, while doing the specific action i.e. ‘connect to outlook’ is always disabled.

Error message:

This control is currently disabled.

Troubleshooting done:

-checked the office version and its already 32-bit office.

-disabled the protected mode of IE

-reduced the high priority of IE to lesser one

-restarted the web client service

-Cross-checked the IE version and make sure it should not be 64-bit version.

-checked the client-integration option by means of web application settings and its already enabled.

Resolution:

-Open the site collection on which you are not able to ‘connect to outlook’

-site actions

-site settings

-manage site features

-There is a feature called "Minimal Download Strategy"

-Deactivate this feature

Once this feature will be deactivated then try to ‘connect to outlook’ please check the results again…

Pretty much sure that your issue will be resolved.

Happy SharePoint to all of U...

Importance of this feature i.e. Minimal Download Strategy

Minimal Download Strategy in SharePoint 2013 improves rendering performance when browsing content where large parts of the page do not change providing a more fluid navigation experience. 

The Minimal Download Strategy is by default enabled on Team sites, Community sites and a few others in SharePoint 2013. Once this feature (and it's also a Feature, notice the capital F, we'll get back to that later) all pages for that site is rendered "through" the /_layouts/15/start.aspx page.

If you have any queries/questions regarding the above mentioned information then please let me know. I would be more than happy to help you as well as resolves your issues, Thank you.

Product applies to:

SharePoint Server 2013

Reference:

Microsoft Outlook 2013 Tutorial | Connecting SharePoint Calendars To Outlook

https://www.youtube.com/watch?v=ULwa6i2g5g4

Removing/Adding a server to query role:

Removing a server out of query role:
- Stopped Office SharePoint Server Search from App server, it should take Problem server out of query role or Clicked on the service Office SharePoint Server Search from the problem server and remove the check box to take it out of the query role. 
- If Stopping it from CA result in error, Error from event logs. and follow the below steps
- Checked events logs and didn't find anything
- Pausing all active crawls from CA.
- Checked the service Process ID from TASKlist command by executing it from the farm admin account. 
- Kill the service from kill /f mssearch.exe.
- Checked from services.msc that Office SharePoint Sever Search is in disable state and from task manager.
- Deleted everything inside E:\index\'Guid ID for index folder' on the server to clear the space, which is having problem.
- Start the crawls.

Adding a server out of query role: 
-  "STOP Timer Scripts Service
- Once  timer service script is stopped. Proceed to add the server to query role.
- In the Service column, click Office SharePoint Server Search.
- On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section:
- Clear the Use this server for indexing content check box.
-Select the Use this server for serving search queries check box.
- Click Start. Then configuration of the application server as a query server is now completed.
- Confirmed from services.msc that service is in start state.
- Need to wait untill the index propegating gets finished if you have another query server in the farm. Watch SSP for the status.
- Once propagation finishes, restart timer services.
- Resume the stopped crawls.

SharePoint General Check-outs

All, Just thought of writting a quick note on the SharePoint General testing we can carry out after every change we do in the SharePoint Farm.
Below listed are the some of the components you can check on.
User end:

• Check if all portals/web applications are responding fine.


• Email Enabled Lib/list.


• Workflows.


• Alerts.


• Add, update, delete list/ lib.


• Add, update, site with Branding (if any).


• Add, remove permisisons.


• Clear recycle bin.


• Check Site Auditing.


• Check Manage Content and Structure.


• Excel Services.


• Infopath Forms.


• Mobile/Blackberry access.


• Outlook Synchronization.


• People picker.

SP admin check-outs

• Central admin access


• Create Site Collection.


• Delete Site Collection.


• Update Site Collection.


• Modify Site Collection admins.


• SSP access.


• Start/Stop/Pause crawls.

Hope this helps you all.

Crawling SharePoint sites using the SPS3 protocol handler

When you setup your content sources in a Microsoft Office SharePoint Server (MOSS 2007), you have a few options to choose from: SharePoint Sites, Web Sites, File Shares, Exchange Public Folders and Business Data. When you use the SharePoint Sites option, you're instructing the indexer to crawl a WSS web front end and you will use sps3:// as the prefix for your start address. This tells the crawler to use a SharePoint-specific protocol handler to enumerate the content and then grab the actual items from the SharePoint server.

A common question here is whether this uses some sort of RPC call into the SharePoint Web Front End (WFE) server. The answer is "no". People asking the question are usually trying to configure the firewalls between a indexer and a MOSS WFE and need to know what TCP/IP ports they need to open. You should be fine with just HTTP (or HTTPS, if your portal requires that). The SPS3 protocol handler uses a web services call (using HTTP/SOAP) to enumerate the content and then uses regular HTTP GET requests to get to the actual items. Crawling using the SPS3 protocol handler requires no RPC calls or direct database access to the target farm. That's the main reason why this type of crawling is supported over WAN links and has a good tolerance to latency.
If you want to confirm this, configure two separate MOSS farms and have one crawl the other:
Configure a new content source using Central Administration, Shared Services, Search Settings, Content Sources, Add Content Source.

Specify SharePoint sites as the type and use SPS3://servername as the start address
Start a full crawl
If you have any network monitoring hardware or software, you will notice that one the first things the crawler will do is use the "Portal Crawl" web service at http://servername/_vti_bin/spscrawl.asmx. The methods in this web service are EnumerateBucket, EnumerateFolder, GetBucket, GetItem and GetSite. It is interesting to see how both "Enumerate" methods will basically return just an "ID" and a "LastModified" datetime, hinting at how SharePoint can do incremental content crawls via this protocol handler... If you just point your browser to that URL yourself, you can find the additional information about the web service, including sample SOAP calls and the WSDL (as you get with any .NET web service). At this point, I could not find much detail on this web service beyond the actual class definition for Microsoft.Office.Server.Search.Internal.Protocols.SPSCrawl.
Here a few pointers to documention that will help you understand the big picture:

There is an overview of this way content sources and protocol handlers work at http://technet2.microsoft.com/Office/en-us/library/f32cb02e-e396-46c5-a65a-e1b045152b6b1033.mspx

You can find some more detailed information and a nice diagram on what a protocol handler does at http://msdn2.microsoft.com/en-us/library/ms974315.aspx

There is also the description of the web services call used at http://msdn2.microsoft.com/en-us/library/ms583576.aspx

Source : http://blogs.technet.com/