PnP.PowerShell is one of my favorite tools of the trade. I’ve had to set up multiple machines for myself or others for this lately, and I always find myself looking for the fastest path to glory. Usually, it takes about 9 articles and 15 blind alleys, so I figured I’d capture what seems to work for me. Hopefully I can keep this up to date if things change.

Install Visual Studio Code

Visual Studio Code aka VS Code aka VSCode aka Code (which I’ll use in the rest of this post) is the “modern”, free code editor from Microsoft. I’ve used dozens of code editors over the years and Code is one of the best. Plus, everyone else is using it!

Obviously, you need to have VS Code installed to start. You can download it from Download Visual Studio Visual Studio Code – Mac, Linux, Windows.

Set Execution Policy

This one gets me every time. You’ll want your Execution Policies set like this:

This allows you to install PowerShell modules with less friction. It’s possible your organization won’t let you make this change. You can see your current settings by typing

Get-ExecutionPolicy -List

in a terminal window. To open things up, run this cmdlet:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

I’m sure there are reasons to set this in different ways based on your organization’s view of security. I’m not going to get into that here: heed your governance rules.

Install PowerShell 7

If you’re running a Windows machine, you’ve most likely got PowerShell 5 (PS5) installed by default. PowerShell 7 (PS7) has more capabilities and is required for PnP.PowerShell to run successfully. Some cmdlets may run just fine with PS5, but don’t be fooled: you want PS7.)

Installing PowerShell on Windows – PowerShell | Microsoft Docs

Install the PowerShell Extension

One of the great things about Code is the rich ecosystem of extensions. The PowerShell extension from Microsoft makes Code smart about PowerShell. You want it.

PowerShell – Visual Studio Marketplace

Switch Code to PS7

I find the instructions for this confusing. PS5 is also called Windows PowerShell (x64) and PS7 is also called PowerShell (x64). In other words, the 5 and 7 don’t show un in the instructions in Using Visual Studio Code for PowerShell Development – PowerShell | Microsoft Docs.

This part is clear:

Use the following steps to choose the version:

1. Open the Command Palette on Windows or Linux with Ctrl+Shift+P. On macOS, use Cmd+Shift+P.
2. Search for Session.
3. Click on PowerShell: Show Session Menu.
4. Choose the version of PowerShell you want to use from the list.

You’ll want to choose PowerShell (x64), if it isn’t already selected.

Pro tip: When you’ve got a PowerShell file (.ps1, .psm1, etc.) open, you can also get to the PowerShell Session Menu by clicking on the squiggly brackets next to PowerShell in the bottom toolbar. Plus, the version is there!

Install PnP.PowerShell

Finally, the piece de resistance: PnP.PowerShell. This is the module that lets us do so much with Microsoft 365. If you’re using the SPO module instead, I say switch.

You need to run Code as an administrator if you want to install modules. To do this, I usually just type Code in the search box in Windows 11, right click the result, and choose Run as administrator.

From here, follow the instruction on the Installing PnP PowerShell | PnP PowerShell page.

Happy PowerShelling!

---

This article is for those of you on a Windows machine. I don’t have a Mac, nor do I want a Mac. I also don’t run Linux. Or a Sinclair Z-80 (though I loved the one I had way back when, it wouldn’t run PowerShell).

I expect I’ve missed a few little bits here. Feel free to tell me so in the comments, and I’ll make updates. Also, let me know if this is helpful!

References

• Migrating from Windows PowerShell 5.1 to PowerShell 7 – PowerShell | Microsoft Docs
• Using Visual Studio Code for PowerShell Development – PowerShell | Microsoft Docs

This is something which has come up in several contexts in the last few months, so I figured I’d put virtual pen to virtual paper and record it for future me and all of you.

If you’ve ever tried to embed content from an external source in a SharePoint page using the Embed Web Part, you may have gotten an error similar to this:

Embedding content from this website isn’t allowed, but your admin can change this setting. They will need to add ‘<specific URL>’ to the list of sites that are allowed.

Guidance on changing site settings

Learn more

It looks something like the screenshot below. It doesn’t matter if it’s a “bare” URL or you’ve encased the URL in an iframe explicitly, like I have below.

When you use the Embed Web Part, SharePoint takes the URL you provide and wraps it in an iframe. An iframe is a way for the browser to display the content inline but protect the page from any malicious actions the embedded site might try to take when it loads. Think of it like displaying a scorpion in a glass box. The scorpion may not have any venom, but since you don’t really know, you leave it in the box. You can see it just fine, but it can’t hurt you.

It turns out the links below the error explain the solution, but I had never clicked those links and read the details! In fact, unless it was years ago, I’ve just ignored the setting we need to solve this.

If you’d like to embed content from a URL, you’ll need to make sure you’ve added the domain name in the site settings. To do this, click on the cog / Site information / View all site settings / HTML Field Security. Here, you can add the domains you’d like to allow to be embedded.

Microsoft provides a default set of common domains, which as of this writing and in my tenant is the following. It’s a bit of an archeology lesson to read through them all!

• youtube.com
• youtube-nocookie.com
• player.vimeo.com
• bing.com
• office.microsoft.com
• officeclient.microsoft.com
• store.office.com
• skydrive.live.com
• powerbi.com
• powerbigov.us
• sway.com
• docs.com
• microsoftstream.com
• powerapps.com
• flow.microsoft.com
• powerapps.us
• flow.microsoft.us
• app.smartsheet.com
• publish.smartsheet.com
• www.slideshare.net
• youtu.be
• read.amazon.com
• onedrive.live.com
• www.microsoft.com
• forms.office365.us
• support.office.com
• embed.ted.com
• channel9.msdn.com
• forms.office.com
• videoplayercdn.osi.office.net
• sway.office.com
• linkedin.com
• web.yammer.com
• customervoice.microsoft.com

You can add the domain you’d like to use in the settings. Once you’d added it to the site, you can embed content from that domain – including its subdomains – in the site with the Embed Web Part.

Note that this is a per site setting. If you want to embed content from the same domain in multiple sites, you’ll need to add it to each site. As far as I know, there’s no programmatic way to add a domain across sites, but I could be mistaken about this.

If you’re feeling loosey-goosey, you could change the setting to allow embeds from any domain, but you may not want to do that for security reasons.

Finally, you must be a Site Owner to change these settings. If you don’t have access to this setting, you’ll need to get help from someone who does.

---

Update 2022-06-07 – Thanks to El_Topo for the comment that we can programmatically update these settings. It led me to an article from Chris Kent (@theChrisKent) entitled Extending the List of Sites You Can Embed From in SharePoint Using PowerShell which explains how to do so. Sometimes I’m the last to know!

In SharePoint – because it’s primarily a collaboration platform – we often struggle with the difference between security and obscurity.

Some content absolutely must be secured, meaning only certain people can see or edit it. In these cases, we set the permissions such that people simply can’t see or even be aware of the content.

Other content should just be kept out of the way by not showing links to it or including it in pages, and this can sometimes be referred to as obscurity. Audience targeting is a form of content management by obscurity: if the content isn’t of use to me, I may not see it, but that doesn’t mean I can’t get to it.

A very common business requirement is to allow people to provide some basic information, like a suggestion for a continuous improvement, their shirt or hat size for a company giveaway, or nominating someone for an award. We can configure the list which contain this information to only show the current user’s items in views, but that’s not necessarily security. If you need them, these settings are in List settings / Advanced settings / Item-level Permissions.

But that’s not the main point of this post. Sometimes the forms are simple and the process is not consequential enough to deserve a Power App or more complex form development. We just want to make the plain old list form available for people to use easily and shield them from the complexity of the underlying list itself. I see solutions all the time where the user is sent to a list view with tacit belief they will know to click the +New button to create a new item in the list. In many workforces, even that is too complicated.

Sometimes Occam’s Razor applies: the simplest solution is the best one.

This is a trick I’ve used many times to make life easier for users and also keep them from plumbing around in the underlying list, even though they may be able to do so due to the permission settings being pretty open.

Some advice, though…

Don’t stick a form like this on the home page of an Intranet site unless you want everyone to see that form as the primary focus for the entire site. I would argue this is rarely the case. In my example, the Suggestion Box is part of the Continuous Improvement site. That effort has to have more to it than just the form.

Here’s the trick. I’m sure I’m not the first person to come up with it, and Emily (@eemancini) probably taught it to me in the first place!

• Create a new page in the site and add some explanatory text and imagery. Let your users know what you’re asking them to do and why it’s useful. A “naked” form doesn’t give them any context.
• Add an Embed Web Part to the page with a URL something like this: https://sympmarc.sharepoint.com/sites/SuggestionBox/Lists/SuggestionBox/NewForm.aspx?Source=https://sympmarc.sharepoint.com/sites/SuggestionBox/Lists/SuggestionBox/NewForm.aspx I’ll break that down below.
• Add a navigation element to the home page of your site to take people to this page.

That ugly URL has the following parts:

• https://sympmarc.sharepoint.com/sites/SuggestionBox/Lists/SuggestionBox/NewForm.aspx – The list’s new item form you want to load in the page. All lists have forms pages, and have since SharePoint 2007:
  • https://sympmarc.sharepoint.com – Your SharePoint subdomain. This is my personal tenant.
  • /sites/SuggestionBox/ – The site where the list lives.
  • Lists/SuggestionBox/ – The list itself. All SharePoint lists live under the /Lists part of the URL path. (Document Libraries don’t.)
  • NewForm.aspx – This is the form you get when you click the +New button on the list pages.
• ?Source=https://sympmarc.sharepoint.com/sites/SuggestionBox/Lists/SuggestionBox/NewForm.aspx – Values after the ? are what’s called the query string. Manipulating what’s hdre has been a nice little arrow in the quiver for years. They are name/value pairs, so here we have:
  • Source – This is a special parameter name when it comes to SharePoint lists. It basically says “when you’re done here, redirect to the following URL”)
  • https://sympmarc.sharepoint.com/sites/SuggestionBox/Lists/SuggestionBox/NewForm.aspx – Yup, that’s the same link we’re loading above.

Your page will look something like this:

As you can see, the form is embedded directly in the page. In actuality, it’s housed inside something called an iframe. You may have heard developers disparaging iframes in the past, but in this case, it works just the way we want it to.

When the user fills out the form and clicks Save, guess where they end up? Right in the same place! So they can submit one or more items – in this case suggestions – without ever knowing there’s a SharePoint list under the covers.

Have you used a trick like this in the past? Do you have any improvements to suggest about this technique?