Monthly Archives: October 2013

Chrome Plug-In Causing Issues

I recently ran into an issue where a SharePoint site wasn’t loading properly, but only for a few users (and only on Google Chrome). This ended up being a Google Chrome Plug-In issue. The plug-in called “Responsive Mobile View” ( caused the SharePoint site to look like this every time you started a new browsing session:



SharePoint 2013 App Part – This content cannot be displayed in a frame

I have been working on a project to setup SharePoint 2013 Apps. Setup went smoothly in test, but when I did the setup on prod something didn’t seem right. Here are the hurdles I had to overcome:

  1. Since the environment is using host headers (which use the server IP address) we had to bind an additional IP address to the NIC. This is because since the wildcard certificate for the primary domain already exists for the main site, we cannot attach the wildcard certificate for the app domain unless we bind an additional IP address and change the CNAME to a wildcard A Record pointing to the new IP (Or create a new A record and then point the CNAME to that..Too much work!).
  2. Now that everything was properly configured and I was able to ping and it returned the new IP address we went ahead and added an app part to a team site. We got an unexpected message where our beautiful SharePoint app should be: “This content cannot be displayed in a frame”…UUUUUGHHHH!
    1. contentiframeerror
    2. If I click the “Open this content in a new window” link it will open a sign in screen. Hmmmm
      1. fbalogin
    3. Now I started comparing differences between test and prod and noticed that the default zone on prod has FBA enabled and doesn’t on test. I was able to replicate this on test by enabling FBA for the default zone. Luckily we don’t need FBA on the default zone and only the extended zone (in this case extranet) so I disabled FBA and called it a day. If you need FBA enabled on the default zone you could create a custom login page that forces integrated authentication.


SharePoint 2013 Foundation – Creating the Search Service with PowerShell and Removing those Pesky GUIDs

I found this awesome PowerShell script on Gary LaPointe’s blog and decided to give it a try. This essentially mimics the SharePoint Configuration Wizard, but it gives you the power to use PowerShell! Below are is my experience with this script and how I went about removing the GUIDs from the database names.

Note: This bases the DB Server off of the default DB Server specified in Central Admin (Can be change using PowerShell Later) and it results in databases with GUIDs at the end, but we’ll remove those later :). Obviously change the Managed Account and App Pool names to fit your environment.

This will result in a default topology, but there are GUIDs..yuck! If GUIDs are unacceptable there is a method of renaming Search Service Databases on I went ahead and tried this out.

1. Run the following commands to suspend the search service

2. Now Go into SQL Server Management Studio and set each Search DB to Read-Only Mode (Accept the message to close existing connections). Right Click Database | Properties | Options. Set Read-Only to True

3. Perform a copy-only backup of each Search Database

4. Detach all of the old databases

5. Restore each database backup (Change Restore to File Names so there are no GUIDS in the MDF and LDF files)

6. Right Click Each Database and Rename (Had a pain with Admin DB. I ended up detaching and reattaching with new name)

7. Restore the old databases (Delete MDF and LDF Files first! May need to close out SQL Mgmt Studio).

8. Use PowerShell to point the Search Service Application at the renamed databases

9. Delete the old Databases with GUIDs

Check it out!


Edit: As Tuppence pointed out below there is now a way to set this up from the get-go. Check out this link:

SharePoint RBS – Failure to BLOB

As seen in my previous post Group Policy can have major effects on the functionality of SharePoint. A recent scenario was that I went on site and got a dev environment up and running with BLOB storage. Everything was thoroughly tested, but when it came time to do the production setup things didn’t go so smoothly. Even following the same exact setup procedure we were only able to upload files in a non-rbs’d database. Any time we would go to upload a file we would be presented with this error: “The URL ‘Documents/doc.docx’ is invalid.  It may refer to a nonexistent file or folder that is nonexistent.” In looking at the correlation ID in the diagnostic logs we notice a more meaningful error:

 “Cannot open log for source ‘RBS’. You may not have write access. —> System.ComponentModel.Win32Exception: Access is denied     –

— End of inner exception stack trace —   

 at System.Diagnostics.EventLog.OpenForWrite(String currentMachineName)“

This indicates that there was a failure to write to the event log. After tracking down the ‘RBS’ log in the registry (The location is HKLM\System\CurrentControlSet\Services\EventLog\Application\RBS) we noticed that it was the Eventvwr Application log.

There are a few ways to adjust access to the eventvwr log, but we decided to use a command-line utility to explicitly grant the appropriate access to the Application log for RBS.

Here are the steps that were performed:

1)      Open CMD as administrator

2)      Wevtutil.exe gl application > C:\temp\out.txt

3)      Add the value (A;;0x3;;;AU) to the end and run

4)      Wevtutil.exe sl application /ca:0:BAG:XXXX (Where XXXX is the values from out.txt with the added entry)

5)      Reboot the server

This value can also be controlled in Group Policy setting “Log Access” under:

Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Event Log Service > Application

Moral of the story: ALWAYS CHECK GROUP POLICY!


FIPS Compliance – Keep away from SharePoint!

SharePoint does not support FIPS compliant algorithms for encryption and hashing: Microsoft has not updated the documentation for SharePoint 2013, but after noticing some issues after an installation I can confidently tell you that it is still not supported. While running scripts to create the SharePoint 2013 Enterprise Service Applications I got flooded with a sea of red error messages for 2 particular service applications: The Secure Store Service and the Search Service. The search service created the required components, but when browsing the Search Administration page it said “Unable to retrieve topology component health states. This may be because the admin component is not up and running.” The Secure Store Service displayed an access denied error (“Sorry, this site hasn’t been shared with you”) every time we tried to manage it in Central Admin. In Eventvwr application logs we noticed the following error (I was able to reproduce this in a test VM):
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
at System.Security.Cryptography.SHA256Managed..ctor()

The key piece here is “Windows Platform FIPS”, which can be enabled in 2 places:
1) Group Policy: Check secpol.msc under Local Policies > Securiy Options. There will be a policy called: System cryptography: Use FIPS 140 compliant cryptographic algorithms, including encryption, hashing and signing algorithms
2) If group policy isn’t enforcing this registry key then possibly FIPS was switched on manually or is part of the O/S image. Check here to make sure the “enabled” DWORD value is not set to “1” here:

Stay away FIPS..stay away