BIFocal LLC

Category: SharePoint 2010

  • Unable to access VMware Workstation Guest after Host Machine crash

    Scenario:

    While doing SharePoint 2010 development is now able to be done from within a Windows 7 64bit system and even inside of a Hyper-V VM, many of us in the wide world of computing are still using VMware Workstation, Fusion, Player, or even the old VMware GSX Server to run local development environments.  This post deals with how to get back into a VM that seems horribly locked after your workstation hosting your VM crashes hard.

    Symptom:

    System crashed while a VMware Workstation Guest was running. The VM now reports that it is in use by the current host. Taking ownership of the VM is not possible.  All hope is starting to fade…

    Solution:

    Go to the VM location and delete the .lck files and folders. This will unlock the VM Guest and allow you to boot in.  VMware treats this like a hard server reset, and offers safe mode booting at that point. If the system is able to recover cleanly, it gets you back to operational.

    Caveat:

    Just like anytime you hard reset a server you must be prepared to deal with the consequences.  Data loss, data corruption, and complete system failure is possible as a result of such action.

    However if you are left with the alternative of complete system rebuild already, it might be worth a shot.  Just don’t blame me if your system is toasty afterwards.

  • Windows with Claims User gets access denied to a site they had access to earlier in the day

    Scenario:

    Small Farm 3 tiered topology using Windows with Claims implementation aggregating AD with a custom LDAP database to create the claims roles.

    Symptom:

    Users of a SharePoint 2010 site get access denied to a site they could access earlier in the day.  As the day goes on, the number of users effected increases.  Eventually only users with full control policies can access the farm.

    ULS Log error:

    An exception occurred in Custom Roles claim provider when calling SPClaimProvider.FillResolve(): The underlying provider failed on Open..

    Root Cause:

    The 10 hour default session timeout for the user’s claim has been exceeded and the database housing the Role Data is no longer accessible.   In this case it was due to an expired SQL account password. Changing the password and updating the connection string or just unchecking the password expiry flag in the SQL account will resolve the issue.

    Notes from the field:

    There was one easy way to prevent this type of user facing outage.  Don’t allow SQL accounts to expire.  EVER.  They are horrible to diagnose because access to the SQL Server is still operational and access using AD authentication is going to throw you off the scent because the main farm access is still available.

    Read Scot Hillier’s blog on “Authorization Failures with Claims-Based Authentication in SharePoint 2010”.  Really useful stuff in there about how claims works and extending the timeouts.