Extending the List of Sites You can Embed From in SharePoint Using PowerShell

The Embed web part for modern pages lets you display content from secure websites right on your page. Want to show a YouTube video? Grab the embed code from youtube.com and slap it in the Embed web part. Wowee!

By default, modern pages support 30+ sites including the most common like YouTube, Vimeo, TED, and internal domains like Stream and OneDrive. But what about when you’ve got content from a site not on this list? You’ll end up with an error similar to this:

Don’t cry! Wipe those tears off that wet face! If you just need to allow the domain for a single site, the instructions are right there (here’s a quick summary):

  • Go to Site Settings
  • Click on HTML Field Security under Site Collection Administration
  • Type the domain from the error message (no https://) into the box and click Add
  • Click OK
  • Give it another try

But wait… Corporate just rolled out a video hosting platform for the enterprise and they want all sites to be able to embed content from this new site. Does the thought of repeating the above steps hundreds or even thousands of times make you weep in despair? Smack those tears off your moistened face!

Here’s a quick snippet of PowerShell which will show you how to add it to multiple sites:

$SiteUrls = @("HR","Accounting","IT")
foreach($SiteUrl in $SiteUrls) {
Write-Host ForegroundColor Cyan "Applying to $SiteUrl"
$FullSiteUrl = "https://superspecial.sharepoint.com/sites/$SiteUrl"
Connect-PnPOnline $FullSiteUrl ErrorAction Stop
$site = Get-PnPSite Includes CustomScriptSafeDomains
$ctx = Get-PnPContext
$ssDomain = [Microsoft.SharePoint.Client.ScriptSafeDomainEntityData]::new()
$ssDomain.DomainName = "special.hosted.panopto.com"

In the PowerShell above, I’m using PnP PowerShell. You can technically do this without PnP PowerShell since it’s just CSOM, but… why would you make your life harder?

Here’s what’s happening:

  • The list of sites in line 1 is just an array of the URL portion of the site after /sites/. You could easily alter this to grab all associated sites for a hub or to get all sites within a classification, etc. But I find a simple list of URLs works pretty well.
  • We connect to the site in line 9 and grab the site object in line 11
  • We get the Client Context in line 12
  • We create a new ScriptSafeDomainEntityData object and set the only part we care about, DomainName, to the URL from the error message before
  • Then in line 17 we use the Create method to add it to the list of domains (there’s no problem if the site already has that domain, it won’t be added twice)
  • We execute the query for the client context to save our changes in line 19
  • Finally we disconnect from the site in line 21 and move on to the next site

You can easily adapt the script above as part of your provisioning process to ensure that new site have the correct domains whitelisted as well. So fun!

Now you can take content from all over the web and mash it together to bring all the relevant stuff directly to your users. WOWEE!

Dog, Pug, Bitch, Pet, Animal, Obedient, Funny, Cute

Scroll SharePoint Search Results Back to the Top on Paging

Applies To: SharePoint 2013+

By default, when you click on a different page using SharePoint’s Search Results web part’s paging links (shown underneath the search results) the next page of results is shown but you remain at the bottom of the page. This is super dumb.


This is really easy to fix and requires no custom code at all! There is a property (not exposed in the UI for some reason) called ScrollToTopOnRedraw that is False by default.

To apply this setting to your Search Results web part, simply export the web part. You can do this by choosing to Edit the page and choosing Export… in the web part dropdown menu:


Now, open the .webpart file in a text editor like Notepad and do a quick find for ScrollToTopOnRedraw. Then change the value from False to True and save the file:


Now, choose Delete in that same web part dropdown menu on the current Search Results web part. Then click the Add a Web Part button. Choose Upload a Web Part under the list of categories, then click Choose File and pick the .webpart file we saved a minute ago. Finally click the Upload button:


You’ll probably be asked if you want to leave the site. It’s safe to choose Leave.

Click the Add a Web Part button again. Choose the Imported Web Parts category and find your newly uploaded Search Results web part and click Add. You’ll likely have to update the Refinement Target for any refinement web parts on the page as well.

Now, when you page results you’ll be taken back to the top of the results each time!

Intermittent “Unable to display this Web Part” messages

Applies To: SharePoint 2010

I few months ago I customized a view in SharePoint designer to turn the due date red for any past due items in the list. The end users really liked this but an obnoxious problem started turning up. Seemingly randomly we would get:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

Correlation ID: Some GUID

Taking a look through our logs didn’t reveal anything and often a refresh or two would solve the problem. So it wasn’t really stopping business but it was pretty annoying. Adjusting the logging settings we finally saw some messages corresponding to the provided Correlation ID and found the issue was Value did not fall into expected range often followed by Stack Overflow exceptions.

Unfortunately the above error message is so generic it was pretty difficult to find anyone else even having the same problem, let alone the solution. Finally I came across this thread on MSDN discussing the exact issue. Instructions for fixing the problem and the background of this issue can be found on this article on Englando’s Blog. The solution presented was to get a hotfix from Microsoft. Fortunately, that is no longer necessary and the fix is provided in the February 2012 Cumulative Update from Microsoft.

The problem was introduced in the June 2011 Cumulative Update when Microsoft reduced the timeout for XSLT transformation (used whenever you customize a view in SharePoint Designer) from 5 seconds to 1 second. This is a good idea for public facing farms to help mitigate Denial of Service attacks but pretty unnecessary for internal farms like the one I was working on.

The timeout causes modified XSLTListView Web Parts and XSLTDataView Web Parts to sometimes show the “Unable to display this Web Part” errors. This is especially true if you have several columns (more transformation) or are doing anything of even mild complexity. The issue was “fixed” in the August 2011 Cumulative Update but broken again in the December 2011 Cumulative Update.

To fix this issue we installed the February 2012 Cumulative Update on our farm (More about our experiences with this update to follow). Keep in mind, however, that the update does not change the XsltTransformTimeOut but merely provides you the ability to do so using PowerShell.

To check your current timeout settings, simply use the following PowerShell:

$myfarm = Get-SPFarm

If you’re experiencing the above problem, you probably got a 1 back from the above command indicating that the timeout is currently set to 1 second. To set it to a more reasonable value (we choose the original 5 seconds) just do this (assuming you set the $myfarm object using the above powershell):

$myfarm.XsltTransformTimeOut = 5

That’s it, things are happy again.

OWSTimer Debugger Annoyances

Applies To: SharePoint 2010, Visual Studio 2010

If you’re running Visual Studio on the same machine with SharePoint 2010 you are probably familar with this error message:

“An unhandled exception (‘System.Security.Cryptography.CryptographicException’) occurred in OWSTIMER.EXE [#]. The Just-In-Time debugger was launched without necessary security permissions. To debug this process, the Just-In-Time debugger must be run as an Administrator. Would you like to debug this process?”

In fact, you are probably very familiar with this dialog since it will pop up at least once a day. If you haven’t logged in in a while, then you will have multiple windows to cancel debugging in.

The problem is due to a threading issue related to an encryption key used by the OWSTIMER service. In SharePoint 2010 the timer service gets recycled daily (default is 6 AM) using a timer job mysteriously called “Timer Service Recycle”. The details aren’t all that important, but you can read more here and get even more information about how the mistake really occurs here. To summarize, the key isn’t found due to impersonation issues. (BTW, that number at the end of the error message is just the process ID and will change each time.)

Bottom line for me is that the error is not really a problem and can safely be ignored in your logs. The annoyance comes when you have Visual Studio installed and the JIT debugger is enabled.

You can either adjust your settings using the registry, or even better, just open up Visual Studio (2010) and adjust your options. Using the menu, choose Tools > Options. Then expand Debugging from the tree on the left (if it isn’t showing, check the Show all settings box) then choose Just-In-Time. To turn it off, just uncheck all the boxes and press OK:

Now those annoying messages will stop and the people will rejoice. Just remember that it can be very helpful to turn these back on when attempting to debug certain types of things (Custom Timer Jobs for instance), but be sure to bookmark this page because you will forget to turn it back off and then you will be sad again and I don’t want you to be sad.

Verifying Constrained Delegation

Applies To: Active Directory

When using Kerberos with SharePoint 2010 you run into the requirement to use Constrained Delegation all over the place. Basically, even though you have the SPNs setup, you’ll need to specify which services your accounts can delegate to by using Active Directory. This is all covered elsewhere and can be found using some simple Google searches so I won’t go into any more detail.

The problem I run into is that I’m not allowed to set this up in Active Directory in our production environment and I have to trust someone else to do this. I don’t mind that, but I do want to be able to check the settings when troubleshooting. Using the Active Directory tools (Here’s a guide to getting these setup), even if you don’t have permission to edit anything, you can take a look at most of the account information. Unfortunately, the delegation tab has everything disabled.

Names hidden to protect the innocent

If you just have a few items setup, then you can see the first six or so, but you can’t scroll down and you can’t expand the entries. Why Microsoft made this impossible to view is beyond me, but you can get to it using the command line.

Since you’ve got the tools installed, fire up a command prompt (Go ahead and Run as Administrator). Then type this command:

ldifde -f C:\ConstrainedDelegation.txt -d "cn=SharePoint AppPool,ou=SharePoint,ou=Services,dc=MyDomain,dc=Com" -l msDS-AllowedToDelegateTo

This will write a list of all the services the account can delegate to (To see all the properties just leave the msDS-AllowedToDelegateTo off the end). Also, make sure you replace the part in quotes with the actual path to your account.

The easiest way to figure out the correct path is to open the Active Directory Users and Computers and expand the OUs (folders) until you find your account. Then take the display name of the account as the cn= part and work backwords up the “folders” specifying ou= for each. Finally, add the dc= for each part of your FQDN. Usually something.something. In the above example, I had expanded MyDomain.com then the Services folder and then then SharePoint folder to find my account named SharePoint AppPool.

In your face Microsoft! I used your tools to get around your tools! Hopefully this can help relieve some of the frustration of troubleshooting Kerberos errors during installation or configuration. Even with the above tip, you’re gonna want a hanky to cry into and a teddy bear to squeeze.

Open with Explorer Intermittent Failures

Applies To: SharePoint


I recently created a new web application that will eventually be used quite a bit, but for now we were only moving one site over. Fortunately, the site collection we were moving was the only thing in the Content Database so I just performed a simple Dismount and then Mount and everything was up and running except for the search results. A quick change of the scopes and a Full Crawl takes care of that. I turned it over to the main user and he immediately called me back and said the Explorer View was not working for him.

Then there was much weeping.


I immediately confirmed that it worked on my machine (Windows 7) and assumed he was doing it wrong (Cause I’m a bit of a Jerk). A quick visit to his machine proved I didn’t know what I was talking about. He was running XP and everything was working fine in our other main Web Application on his machine for Explorer View, but not in the new Web App.

He would receive an access denied message stating he didn’t have enough permissions but also that the Network Path was not found. I decided to investigate further at my machine only to find that mine only worked intermittently. Sometimes it would open up just fine, but other times I would receive the message “Your client does not support opening this list with windows explorer.” Something had made my machine a liar.


After a bunch of searching and cross comparing my Web Apps to see what setting I missed, I came across this article on The prostructure blog. Amber Pham lays out the full solution there which I am reproducing here. She got it right but it was so hard to find that I thought rephrasing some things might help the next poor victim find the solution quicker. So it’s below, but it is her solution and I’m very grateful for her help.


Turns out, for whatever reason, a missing root site for the Web Application will cause this issue. Since I was only moving the one site for now, I hadn’t yet created a Site Collection at / (Root Site Collection). I didn’t think this was a big deal – and if you’re not using Explorer View, it’s not. But to correct this issue, go into Central Admin and create a new Site Collection at /. Pick any template you want since you can always change it later. I just ensured that I was the only one who had access to it for now and voila, Open with Explorer suddenly works for my XP clients and consistently works for our Windows 7 clients. Sheesh.

SharePoint 2010 Ribbon Weirdness

Applies To: SharePoint 2010

I was recently helping a user with their SharePoint site on their machine and I noticed some weirdness with the ribbon display. The Tab names were all truncated and too small and their User Name (Menu) was not showing in the upper right corner. Obviously, this concerned me.

Some quick searching didn’t turn up anything and I couldn’t reproduce it on my end. Then 2 days later I was helping someone else and they had the same display problems. Checked their version of IE and they were exactly the same (8.0.6001.18702CO)! But I believe the problem can happen with any version of IE 8.

With this new information did another quick search and found this quick article from Microsoft: http://support.microsoft.com/kb/2062185 where they indicate the Zoom feature is causing the problem.

Sure enough, adjusting the zoom back to 100% fixed the display issue. Strangely, IE 8 seemed to be handling zoom levels in increments of 10 just fine (110%, 120%, etc.) but custom zoom levels (like 128%) freaked it out.

This is problematic because it looks like a problem with the site and adjusting your zoom level is as easy as holding the CTRL key while using the middle mouse scroll. I found that I couldn’t reproduce the problem with IE 9. Until we can get everyone upgraded (a major process around here), it’s just a matter of education among our support staff and end users.

Fixing SharePoint Office Integration Problems

Applies To: SharePoint

We recently upgraded to SharePoint 2010. Things went relatively smoothly, but we began to experience problems with some of our Office users. I looked everywhere but I couldn’t find anything that described our problem perfectly or that provided a solution. So here is the guide I wish we’d had before we called Microsoft Support.


Windows 7/Vista machines had missing/broken links to the sites within the SharePoint Sites library on their machine. These were all users with MySites most of whom had had no problem opening and saving documents directly within Office to SharePoint 2007. This was affecting both Office 2007 and Office 2010 users.

The Save/Open dialog showing a normal SharePoint Sites Library

Sometimes there was a MySite link, sometimes just a Member Sites folder, sometimes neither and sometimes various levels of Member Sites with the wrong type of Icon (Not like shown above). Some users could connect fine although it was very slow, others would have some very strange issues.

In addition to constantly asking for authentication or telling them access was denied to their own MySite, there were users who seemed to be saving their documents nowhere. Checking the Upload Center would show they did save them but not as expected.

For instance, one guy added his personal documents library to Office using the Connect To Office button on the SharePoint Ribbon. Trying to save a word document he double clicked on this link within the SharePoint Sites Library and everything saved. Further investigation with SharePoint Designer showed that their was a word document at his MySite root named PersonalDocuments.aspx.doc!

Obviously these links were broken. Sometimes they were gone from one day to the next and this was causing a lot of frustration. We tried messing with the registry entries, checking our version of Office, verifying access was setup correctly and finally gave up and called Microsoft Support.

Our Environment:

We had had a SharePoint 2007 farm using Windows Authentication. We built a new SharePoint 2010 farm and used the Database Attach upgrade approach. The new farm was built to use Kerberos authentication. When everything was good to go we switched the DNS entries to the new farm and voila, everything worked! (Obviously excluding the weird Office problems).

Our clients are mostly XP machines running Office 2007 – these had no issue. The Windows 7 clients running both Office 2007 and Office 2010 began experiencing the problems even though everything worked fine with SharePoint 2007.

Our DNS entry for SharePoint was set to the FQDN (ie sharepoint.something.something). Although alternate access mapping was setup for just the sharepoint portion, the FQDN is the only public url. This turned out to be the problem.

The Cause of the Problem:

The solution was found in this Microsoft Support article: Prompt for Credentials When Accessing FQDN Sites From a Windows Vista or Windows 7 Computer

In summary, the Web Client service uses Windows HTTP Services (WinHTTP) to do network operations behind the scenes (including requesting the list of Member Sites and MySite urls to update your SharePoint Sites Library). WinHTTP only sends user credentials in response to requests that occur on a local intranet site.

So just add your site to the Trusted Sites list and you’re done! Just kidding, that’s far too easy! WinHTTP does NOT use the security zone settings in Internet Explorer to determine if it should send the credentials. Instead it uses some pretty basic logic:

Are there any periods in the server’s name?
Nope: must be local – send them credentials!
Yes: Eeeek! Evil Internet, no credentials for you!

So if you happen to be using a FQDN or anything else with periods in the address, unless you’ve setup a local (no perioded(?)) proxy, no authentication is gonna happen which is pretty problematic for nearly every use case in SharePoint.

A hotfix is available for Vista and was included in Windows 7. But the hotfix doesn’t fix the logic nor does it start using the security zone definitions from your internet options. It provides a registry configuration of trusted sites (see solution below).

Testing the Problem:

Office only requests this list of sites/libraries once every 24 hours or so based on a registry key. However, following the steps below you can get it to make the request(s) again. In order to watch them, download and install Fiddler. You should be able to see all the requests as it makes them.

Close all Office programs (including Outlook)

Using RegEdit, delete the LinkPublishingTimestamp registry key.

Vista and Above:

If you are using Office 2007, just replace the 14.0 used above with 12.0

Restart the Web Client service using the Services console (Administrator Tools > Services or Run services.msc)

Open Word and choose Save As (It may take a few minutes to start populating).

In Fiddler you should see all or at least most of the requests receive 401 responses (unauthorized). So, let’s get it fixed.


  1. Using RegEdit, navigate to the following key:
  2. Add a New Multi-String Vlaue (Edit > New).
  3. Name it AuthForwardServerList and press Enter.
  4. Set the value (Edit > Modify) to your FQDN. Or you can do something more comprehensive like http://*.something.something
  5. To verify it worked follow the steps above and see if everything updates (Or wait a day for things to recycle)

Now slap that registry setting in a Group Policy targeted at Windows 7/Vista users and you’re good to go.