James Callaghan

Tag: Troubleshooting

  • Long live the best SharePoint ULS Viewer

    Long live the best SharePoint ULS Viewer

    Update (15th June 2014): We may see a return of the SharePoint ULS Viewer very soon. Jeremy Thake and Office Dev indicated it is coming back to life very soon.

     

     

    Community Discussion (9th June 2014): SharePoint Consultant and MVP Vlad Catrinescu has started a discussion about possible replacements for the ULS Viewer on the SharePoint Community site (http://sharepoint-community.net/forum/topics/what-is-the-best-replacement-for-ulsviewer).

    After noticing a tweet from Brian Lalancette ‏(@brianlala, you might also know him through his AutoSPInstaller project), I gasped at the thought that the best ULS Viewer for SharePoint is no longer going to be available.

    Along with many others in the SharePoint community, I was quite surprised by this news and started to consider what alternative was available. I’ve used the ULS Viewer from MSDN so many times I have lost count and don’t know where I would be without it.

    The best ULS Viewer
    The best ULS Viewer

    For those who’ve found this post and just want to download a copy of the ULS Viewer tool, you’re in luck. I have preserved a copy of ULS Viewer as a .exe and a .zip archive – these are available here http://bit.ly/UlsViewer and http://bit.ly/UlsViewerzip.
    You might receive a warning from the URL shortening service when using the .exe link warning against directly downloading an exe – this is why I have also provided a ZIP version.

    Other SharePoint ULS Viewer tools…

    As the ULS Viewer is no longer available I thought I shared some alternative tools or techniques to get access to the SharePoint ULS logs.

    ULS Studio

    A Codeplex project that I’ve used on several occasions and does somewhat come close to the features that the ULS Viewer tool had – ULS Studio (https://uls.codeplex.com).

    ULS Studio
    ULS Studio

    CSOM for SharePoint Online

    If you’re using SharePoint Online you could follow Vardhaman Deshpande’s blog post (http://www.vrdmn.com/2014/03/view-tenant-uls-logs-in-sharepoint.html) and access the ULS logs using the Client-Side Object Model (CSOM).

    SPO ULS with CSOM - Vardhaman Deshpande
    SPO ULS with CSOM – Vardhaman Deshpande

    Developer Dashboard

    There’s also the ULS tab within the Developer Dashboard, although this is limited to reviewing errors related to those requests where the Developer Dashboard is displayed or used.

    The Developer Dashboard can be activated using PowerShell – SharePoint Developer Devendra Velegandla shares the PowerShell and reviews the Developer dashboard on his blog (http://www.sharepoint-journey.com/developer-dashboard-in-sharepoint-2013.html).

    $svc = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
    $dds = $svc.DeveloperDashboardSettings
    $dds.DisplayLevel = "On"
    $dds.Update()
    ULS errors displayed in the Developer Dashboard
    ULS errors displayed in the Developer Dashboard

    PowerShell

    Use can even use PowerShell to get details about a correlation error. Wictor Wilén shares details about this method in an article on his blog (http://www.wictorwilen.se/Post/Working-with-SharePoint-2010-Correlation-ID-in-PowerShell-and-code.aspx).

    Get-SPLogEvent | out-gridview
    Get-SPLogEvent | Out-GridView
    Get-SPLogEvent | Out-GridView

    Summary

    While I’m not going to stop using the ULS Viewer – I can only recommend you use something to help you view the SharePoint ULS logs. Troubleshooting SharePoint is not easy but you can help yourself, firstly by always checking the event log and secondly being comfortable with your method of doing.

    Long live the best ULS Viewer.

  • Error when creating new Site Collections via Central Administration

    Error when creating new Site Collections via Central Administration

    A customer recently reported that they were not able to create any new Site Collections within any Web Application in their SharePoint 2013 UAT environment. Instead of being able to create a new Site Collection they repeatedly received the error shown in the image below.

    Provider must implement the class 'System.Web.Security.MembershipProvider'.
    Provider must implement the class ‘System.Web.Security.MembershipProvider’.

    I in order to troubleshoot this issue I tried creating a Site Collection myself while monitoring the ULS logs. An event with an ID of 8307 was appearing in the logs each time I tried to create a new Site Collection. This event had a message of “An exception occurred in Forms claim provider when calling SPClaimProvider.FillResolve(): Provider must implement the class ‘System.Web.Security.MembershipProvider’. (C:\inetpub\wwwroot\wss\VirtualDirectories\34596\web.config line 606)”.

    ULS Viewer
    ULS Viewer
    Event 8307. SharePoint Foundation. Claims Authentication.
    Event 8307, SharePoint Foundation, Claims Authentication.

    This suggested a problem with the web.config for the Central Administration Web Application and an error with a Membership provider. Forms Based Authentication (FBA) has been used to configure FBA in this environment so I continued exploring this avenue further.

    I reviewed the web.config at the line indicated from the event and noticed that there were multiple entries for FBA membership and role providers. I removed these duplicate entries and was able to create Site Collections without any problems then.

    As the Forms Based Authentication in this environment was configured using the FBA Configuration Manager I can only think that this was at fault somehow – the odd thing is that the same tool was also used on to configure the production environment which I also confirmed was not also having the same issue.

    I would suggest that after using the FBA Configuration Manager to configure FBA that you ensure you can create new Site Collections. It’s certainly something I am going to be including to my deployment checklist!

  • Configuring a host name with a SSL Certificates in IIS 7

    Configuring a host name with a SSL Certificates in IIS 7

    A customer asked me if I could help troubleshoot their SharePoint environment – they had extended a web application and configured it to use Forms Based Authentication (FBA) with SSL however they were getting errors when accessing the new site.

    I started troubleshooting the configuration across all the servers in their SharePoint 2013 farm. I stepped through the configuration for the web application in Central Administration – reviewing the authentication provider settings and alternate access mappings. I then reviewed the web.config and made sure that the FBA settings were present and correct along with the IIS website bindings. This is when I noticed that there was no hostname against the https/443 binding –  the option to add one was also disabled.

    IIS binding - host name disabled
    IIS binding – host name disabled

    After a little research, I found an article from ArmgaSys.  It turns out that my customer’s wildcard SSL certificate was issued without an * in the name, therefore, the hostname cannot be specified once the SSL certificate is selected. I followed the steps in this article from and the customer was able to access their SharePoint site without any errors this time.

    IIS binding - host name editable
    IIS binding – host name editable

    A summary of these instructions are included below: –

    1. To resolve this and make the hostname field editable launch Microsoft Management Console (MMC) and open the Certificates snap-in.
    2. Locate the wildcard certificate, right click on it and select properties.
    3. If the Friend Name property doesn’t start with a * then add one and apply any changes you make.
    4. Now go back to IIS and select the SSL certificate in the bindings of the SharePoint website with the issue.
    5. The hostname field should now be editable where you should then enter the hostname for your SharePoint site.
  • Workaround to “the server is temporarily unavailable” when signing into Lync 2013

    Workaround to “the server is temporarily unavailable” when signing into Lync 2013

    Since our Office 365 tenant was upgraded we’ve been experiencing difficulties with our users signing into Lync 2013. When these users tried to sign in, the Lync 2013 client returned an error saying it could not communicate with the server. The users received the following error.

    “The server is temporarily unavailable.”

    The server is temporarily unavailable
    The server is temporarily unavailable

    Background

    Firstly our IT guy raised this issue with Office 365  through a support ticket some months ago when we started experiencing this issue. There was some back and forth communication however no solution was ever found. As far as I know, the issue is still open.

    A few months passed and I was getting more and more frustrated that I wasn’t able to communicate with my team using Lync so I decided to spend some time and see if I could find a solution myself.

    Here is some other background information about our configuration…

    • Domain joined machines using Office 2010 were ok
    • Mobile clients were fine
    • All users are part of a Windows 2008 R2 Active Directory domain that is not connected to Office 365 through ADFS or DirSync
    • User accounts experiencing the issue have spaces in their account name (Joe Bloggs)
    • The Office 365 DNS records are set up correctly – even broke out fiddler and checked my Lync client was reaching it’s end-points correctly which they were
    • Our internal domain is using an unresolvable .local address

    After reading countless forum posts I noticed many others were reporting similar issues and the issue seemed quite widespread.

    So after some research, I read that Microsoft was aware of the bug and did not expect it to be resolved until September time. Others were saying that it worked with users whose machines were not joined to an Active Directory domain. This leads me to think about try using a local account and there it is folks – my solution!

    This is less of a solution but more of a workaround whilst Microsoft fix this issue once and for all!

    1. Kill the “lync.exe” process (use Task Manager to end the process)
    2. Create a new local user account on the computer (lusrmgr.msc)
    3. Add this account to the Administrators security group
    4. Navigate to the Program Files directory for Lync 2013 (C:\Program Files\Microsoft Office 15\root\office15\)
    5. Whilst holding the SHIFT key down, right click on the “lync.exe” application and select “Run as different user”
    6. Enter the username and password of the account that was just created
    7. Lync 2013 should open and launch the “New user configuration” window
    8. Sign in to Lync 2013 with your Office 365 username and password
    9. The Lync 2013 client should now happily work

    I should highlight that some features such as creating a Lync meeting through Outlook might not work due to the processes running as different user accounts. Try it out for yourself and see.

    Fingers crossed Microsoft fix this issue pretty soon!