Archive | SharePoint RSS feed for this section

Fixing QueryFeatures Error When Looking for Features to Upgrade

26 Jun

UPDATE 11/9/13: Added SourceCode Formatting

PROBLEM:

I was running QueryFeatures on the SPWebApplication to find a SPFeature object to upgrade, but was receiving an error about a deleted site.

An error occurred while enumerating through a collection: The site with the id 8e79d05f-3f0c-4627-8311-7d29b2a2c4a3 could not be found..
At line:1 char:1
+  <<<< (Get-SPWebApplication http://www.devsite.com/).QueryFeatures(‘afda6a62-4389-402f-af19-11bd9ee2b99a’) | ?{$_.Parent.Url -like "http://www.devsite.com/specific/site"}    + CategoryInfo          : InvalidOperation: (Microsoft.Share…esultCollection:SPFeatureQueryResultCollection) [], RuntimeException    + FullyQualifiedErrorId : BadEnumeration

Simon Doy does a good job of explaining the issue in more detail. I had previously created and deleted a site collection for testing purposes and that is when my problems started.

SOLUTION:

To solve the issue I started by running the Get-SPDeletedSite command to find the problem sites. I then removed the deleted sites with Remove-SPDeletedSite. Next, I ran a refresh on the content database to make sure the list of sites was update in the configuration database. The whole PowerShell process looked a little something like this:

PS C:\Users\beavel> Get-SPDeletedSite

WebApplicationId   : 00000000-0000-0000-0000-000000000023 
DatabaseId         : 00000000-0000-0000-0000-000000000024 
SiteSubscriptionId : 00000000-0000-0000-0000-000000000000 
SiteId             : 8e79d05f-3f0c-4627-8311-7d29b2a2c4a3 
Path               : /team/site1 
DeletionTime       : 6/25/2012 8:32:31 PM

WebApplicationId   : 00000000-0000-0000-0000-000000000023 
DatabaseId         : 00000000-0000-0000-0000-000000000024 
SiteSubscriptionId : 00000000-0000-0000-0000-000000000000 
SiteId             : 5fcf2a3b-ee9e-4d27-8e7b-4c7185396dce 
Path               : /team/site2 
DeletionTime       : 6/25/2012 8:18:48 PM


PS C:\Users\beavel> Remove-SPDeletedSite -Identity 5fcf2a3b-ee9e-4d27-8e7b-4c7185396dce

Confirm 
Are you sure you want to perform this action? 
Performing operation "Remove-SPDeletedSite" on Target "/team/site2". 
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help 
(default is "Y"):y 
PS C:\Users\beavel> Get-SPDeletedSite

WebApplicationId   : 00000000-0000-0000-0000-000000000023 
DatabaseId         : 00000000-0000-0000-0000-000000000024 
SiteSubscriptionId : 00000000-0000-0000-0000-000000000000 
SiteId             : 8e79d05f-3f0c-4627-8311-7d29b2a2c4a3 
Path               : /team/site1 
DeletionTime       : 6/25/2012 8:32:31 PM</pre>

<pre>PS C:Usersbeavel> Remove-SPDeletedSite -Identity 8e79d05f-3f0c-4627-8311-7d29b2a2c4a3

Confirm 
Are you sure you want to perform this action? 
Performing operation "Remove-SPDeletedSite" on Target "/team/site2". 
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help 
(default is "Y"): 
PS C:\Users\beavel> $db = Get-SPContentDatabase -Identity 5a83c168-d8e8-44c7-b5d3-46b8d87d9a06 
PS C:\Users\beavel> $db.RefreshSitesInConfigurationDatabase()

I was still running into issues with my original command. To get things working, the “Gradual Site Delete” time job needed to be run for the Web Application that contained the two sites. This was run from Central Admin instead of PowerShell. Once it had completed, I was again able to run my original command. I’m not sure the DB refresh was needed in this process. You may be able to get by without it as I have not tested.

Advertisements

SharePoint 2010, compat.browser, & the Saga of Safari and Chrome

23 Sep

Situation:

Working with a public anonymous site hosted on SharePoint 2010 there was an issue with the mobile view on certain devices. Anybody who has worked with SharePoint knows that by default it will do browser detection for mobile browsers and render a mobile version of the site OOTB. Although this can be helpful with some browsers, most mobile touch screen devices make the need for a specific mobile version unneeded.

The specific issues we were facing are listed below:

Issues:

  1. The files required for the mobile view are located in a directory which was not accessible anonymously causing a 401.
  2. Files that were in the Style Library were not accessible for certain browsers, but worked just fine on other browsers.
  3. Changing the compat.browser file located in inetpubwwwrootwssVirtualDirectories{WebAppFolder}App_Browsers allowed all browsers to see the full site, but the changes caused problems for Safari and Chrome on the desktop as well on mobile devices.

Solution:

For issue #1, we did not want to display the mobile version of the site so the solution was to make sure browser detection stopped rendering the alternative version. This lead to first testing the site by appending ?mobile=0 (http://www.site.com/Pages/default.aspx?mobile=0) to the end of the URL so that SharePoint would skip the browser detection. This revealed issue #2.

Although the mobile view was no longer rendered, the styling on the page was severely off. Users of Windows Phone 7 and desktop browsers were rendering the site just fine, but Android and iPhone devices rendered without proper styling. By looking at IIS logs, I noticed that Android and iPhone devices were getting 401’s when trying to connect to the Style Library. This is where a number of key .js and .css files were stored so it made sense that the site did not render properly. This next part is purely conjecture on my part, but I believe the discrepancy between devices came down to NTLM support. Although the site had anonymous access turned on, the Style Library on a Publishing site does not inherit permissions therefore when anonymous access gets turned on it does receive the anonymous permissions unless directly specified. This can go unnoticed for browsers/OS’s that support NTLM as the Style Library has the group Style Resource Readers on it which contains NT AUTHORITYauthenticated users. My assumption is that browsers that support NTLM use the special user NT AUTHORITYiusr to connect and it is considered authenticated and therefore the site rendered properly for most OS’s and browsers. IIS logs seem to support this as NT AUTHORITYiusr shows up when accessing the Style Library. The solution here was simply to add anonymous access to the Style Library. With this done, appending ?mobile=0 now rendered the site as expected. This left the final issue.

The next step was to turn off browser detection so that no devices were being sent to the mobile experience. From reading various sources, the compat.browser file needed to be edited to set isMobileDevice to false. I wrote a PowerShell script to quickly replace all instances. Find and replace probably would have worked as well, but I like trying new things in PowerShell. With my modified compat.browser file ready, I took and replaced it in our test environment and everything worked as expected. I then moved it to our Production environment and this is where issues started. In Production, the menu system was not being rendered properly on Chrome and Safari. Thinking the issue was related to my change, I reverted to the original file thinking this would fix the problem. It did not. A number of other solutions such as file permissions, editing other compat files, and adding .browser files were attempted but they were unsuccessful at resolving the problem. It wasn’t until we were able to successfully break another system that we stumbled on the answer. Deleting the compat.browser file and then browsing to the site successfully replicated the issue on a dev server. Restoring the file would no longer fix the issue. Server reboots also failed. The final solution turned out to relate to the second file in the App_Browsers directory which is the compat.moss.browser file. When this file was deleted from the directory and the site was visited, the problem went away. The compat.moss.browser file could then be restored without ill effect. My recommendation DON”T DELETE compat.browser when editing. It seems like the “stickiness” of this issue would be considered a bug as one would assume restoring an original file would fix the issue, but it did not. Hope this saves someone else the same headache.