Friday, April 26, 2013

Your client does not support opening this list with windows explorer windows 2008


 Error message
“Your client does not support opening this list with Windows Explorer" when you try to "Open with Explorer" on a SharePoint document library

Troubleshooting:

  • Treid to open in Windows  XP. Works fine.
  • Treid to open in Windows Server 2003, gives error messsage.
  • Treid to open in Windows Server 2008, gives above error message.
  • Removed the ‘s’ from the http protocol.
  • Supplied the correct user name and password.
  • Started the ‘webclient’ service and installed desktop support expirence as a features in Windows server 2008. Still does’t work.


Resolution:


Steps Featuring artcile:

Applied to:

  • Windows Server 2008
  • SharePoint Server 2010.


How to hide "Respond to this Survey"


Problem Description:
How to hide "Respond to this Survey" when a user has already responded to the Survey

It’s simple but little bit tricky to implement as it involves user controls also.

Imp point to note:
·         The Rendering Template for the Survey List is in the defaulttemplates.ascx
Control under 12/Template/Control template.

·         The rendering template ID is ‘ViewToolBar. This template renders the "Respond
to this Survey", Actions menu and Settings menu in the toolbar.

·         This template is a generic template which is used by other lists as well.

·         "Respond to this Survey" is rendered by <SharePoint:NewMenu
AccessKey="<%$Resources:wss,tb_NewMenu_AK%>" runat="server" />.

How exactly it looks like:
<SharePoint:RenderingTemplate ID="ViewToolBar" runat="server">
<Template>
<wssuc:ToolBar CssClass="ms-menutoolbar" EnableViewState="false" id="toolBarTbl"
ButtonSeparator="<img src='/_layouts/images/blank.gif' alt=''>"
RightButtonSeparator="&nbsp;&nbsp;" runat="server">
<Template_Buttons>
<SharePoint:NewMenu
AccessKey="<%$Resources:wss,tb_NewMenu_AK%>" runat="server" />
<SharePoint:ActionsMenu
AccessKey="<%$Resources:wss,tb_ActionsMenu_AK%>" runat="server" />
<SharePoint:SettingsMenu
AccessKey="<%$Resources:wss,tb_SettingsMenu_AK%>" runat="server" />
</Template_Buttons>
<Template_RightButtons>
<SharePoint:PagingButton runat="server"/>
<SharePoint:ListViewSelector runat="server"/>
</Template_RightButtons>
</wssuc:ToolBar>
</Template>
</SharePoint:RenderingTemplate>

Microsoft Recommendation:
1.    We cannot modify OOB defaulttemplates.ascx as this would be unsupported
2.    Make a copy of defaulttemplates.ascx under CONTROL TEMPLATES FOLDER of 12 hive
and rename it to CustomDefaultTemplates.ascx
What exactly needs to done/Resolution:
1.    To hide “Respond to this Survey” if a user has already responded to the survey,
Create a class which inherits from the Microsoft.Sharepoint.WebControls.NewMenu.

2.    In this override CreateChildControls and have your logic to hide unhide "Respond
to this Survey" based on your need.

3.    Build the class library and install the dll to the GAC.

4.    Modify the “ViewToolBar” in the custom ascx such that to render your custom
"Respond to this Survey" menu from the class library you created.

(Note: You need to add your assembly reference and register the tag prefix in the
Custom ascx control.)

5.    Next step is to render the custom rendering template to the "Survey List" so
     that the custom "Respond to this Survey" menu will be rendered in the toolbar.

6.    For this the "ToolbarTemplate" property of the View should be changed in the
schema.xml file of the Survey List definition.

7.    As modifying the OOB files are not supported, Copy the “SurveyList” folder from
12/Template/Features and paste in the same place as “CustomSurveysList”.
Change the feature ID of the “CustomSurveyList”

8.    Open the schema.xml file available under survey folder of “CustomSurveysList”
and add the “ToolbarTemplate=CustomViewToolBar” attribute to the “View BaseID=0”.

Example attached:
<View BaseViewID="0" FreeForm="TRUE" ReadOnly="TRUE" Type="HTML" ToolBarTemplate=" CustomViewToolBar ">

9.    Install and activate "CustomSurveysList"

10. Create a Survey List using CustomSurveyList template and we should be able to
achieve the functionality as required.

Customizing the SharePoint 2013 Developer Dashboard using custom scripts


In SharePoint 2013 Dev dash has helped the admins to help troubleshoot a lot of performance issues .The Developer Dashboard can now be extended by injecting custom JavaScript code into the developer dashboard window.

Your current Contributor Settings prevent you from creating, editing and deleting workflows


Error Message:
Your current Contributor Settings prevent you from creating, editing and deleting workflows

Probable Cause: 
By Default the Contributor Settings will be enabled on your site. You will notice this in the SharePoint Designer task pane.

Resolution:
This is because your account is present in the Content Authors group, which may “Restrict the use of some features” as the task pane mentions. This behavior can be modified if you turn off the "Contributor Settings" in SPD.

1. Open the site in SharePoint Designer
2. Site Menu
3. Choose Contributor Settings.
4. Click on Disable Contributor settings
5. Refresh the page you should not see the message. 

Important Information:
If you are a site manager or administrator, you are probably working with various groups such as Web designers or content authors who are working on different aspects of a Web site. With so many groups working simultaneously, you are probably worried that somebody might inadvertently break a site — for example, by changing the design of the home page, modifying the style sheet, saving files in a wrong location, or breaking the site navigation or search functionality. If you are concerned, the good news is that you can avoid these scenarios by using Contributor Settings to turn on and configure Contributor mode in Microsoft Office SharePoint Designer 2007.

The Windows PowerShell Debugger


In Windows PowerShell 2.0 (the November 2007 Community Technology Preview release) the PowerShell team has taken an interesting approach to script debugging. As you know, PowerShell doesn’t require a specialized script editor or development environment. Instead, PowerShell users can, and do, use any and all text editors (from Notepad on up) to write their scripts. Because of that, the PowerShell team decided to build their debugging tools into Windows PowerShell itself; in turn, that means that you can use the new debugging cmdlets to debug any script from the console window itself.