How to download video offline from Office 365 Video

Office 365 Video is a media sharing solution which is part of Office 365. It allows users to upload, play, share, embed, group in channels and manage their videos. The feature which is currently missing is downloading a video.

Under the hood

To get to the part of downloading the video we need to understand what is happening under the hood of Office 365 Video. Videos are grouped in channels. For each channel a site collection is created. This is not shown to the end user but is mandatory information to actually download the video. All videos are uploaded to this site collection in an Assets library. This library is accessible via the browser!

Download the video

We know now that the videos are part of a Assets library. How do we know where this Assets library is located? This is fairly easy, because the name of the channel is the name of the site collection.

For example our channel is named “Corporate News”. The underlying site collection has the URL Via the settings menu we can navigate to “Site Contents” and click on the Assets library. Although the name is has a technical reference, thus not really readable. The Assets library name for the videos is “


Office 365 Video channel site contents

Luckily the URL to the Assets library is more straight forward

Downloading the video is simple, just select the video and use the context menu and click “Download”.

Office 365 Video assets library, download a video

Office 365, where can I find my assigned license?

In Office 365 users require licenses for making use of the products. This is similar as on-premises. The corporate administrator assigns licenses in the Office 365 Admin Center or uses PowerShell for automation purpose.

Office 365 Admin Center - Assign License

The challenge I faced was around getting insights into the licenses which were assigned to me as an user. Most of the times I have access to the Office 365 Admin Center due to my role as consultant. But now I don’t have access, but there is still a way to see my assigned licenses.

The screenshot above shows the Office 365 Admin Center – Active Users page where licenses can be assigned to users. The link is

The user “admin admin” has all licenses assigned. Although he has access to the Office 365 Admin Center he can see his licenses from the new Office 365 Profile Page. Check out your assigned licenses at

Office 365 - Profile Page (assigned licenses)

The SharePoint CSOM assemblies and the “The specified module could not be found” error

When working on my community project SharePoint Client Browser I received multiple times the issue which related to the error message “The specified module could not be found”. The error log shows the error is thrown while authenticating with SharePoint Online.

File '' not found, check log file for detailed information. System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E) at Microsoft.SharePoint.Client.Idcrl.ManagedIdcrl.EnsureInited() at Microsoft.SharePoint.Client.Idcrl.ManagedIdcrl.LogonIdentity(String username, SecureString password) at Microsoft.SharePoint.Client.SharePointOnlineCredentials..ctor(String username, SecureString password) at SPBrowser.Entities.TenantAuthentication.InitClientContext()

What is weird about this, although a FileNotFoundException is thrown, the exception details do not indicate which file is actually missing. #Fail!

What also did not help with resolving my issue was missing automated packaging of the SharePoint Client Browser tool. This is definitely one of those reasons to automate your build process. To ensure the package contains everything it needs, instead of missing a single file due to manual packaging.

So, we do we actually need? When building a solution based on the SharePoint CSOM we require a set of assemblies. Depending we are building for SharePoint 2013 (v15) or SharePoint Online (v16) we need a different set. But what was causing the issue was not one of the CSOM assemblies!

Required assemblies for both SharePoint v15 and v16:


SharePoint CSOM assemblies:

  • Microsoft.SharePoint.Client.dll
  • Microsoft.SharePoint.Client.Runtime.dll
  • Microsoft.SharePoint.Client.Taxonomy.dll

Whatever you release in a package, make sure you include the MSOIDCLIL.DLL and MSOIDRES.DLL assemblies!

Enable ULS logging during App deployment

Troubleshooting is always afterwards, meaning you need logging information to backtrack the origin of the errors. But normally the logging level is set to default and the actual interesting data is missing from the ULS logs.

This post provides an approach to enable logging before deploying your apps and reverting to the default afterwards.

Before making changes to the ULS diagnostic settings you want to backup/export your settings. Doing this from the Central Administration is not your preferred way or you must love to copy and past a lot.


Export the diagnostic logging levels

You can easy export your settings by using PowerShell. Below a script which exports the diagnostic settings for the ULS logging levels. This script will export the logging levels to a CSV-file.

Get-SPLogLevel | Export-Csv "$($env:USERPROFILE)\Downloads\$((Get-Date).ToString("yyMMddHHmmss"))_LogLevels.csv" -NoTypeInformation

After opening the export in Excel, you get the data shown below.


Use PowerShell to get and/or update logging level

To get and/or update a particular log level via PowerShell you need to know how to scope the identity of the logging level. Once you know it, it’s pretty simple! The identifier is a combination of Area and Name.

Get-SPLogLevel -Identity "Search:General"

Change logging levels for App deployment

The general steps you want to include in your deployment scripts is based on lowering the logging for a predefined set of logging levels. Next execute the deployment and afterwards revert to the default.

  • Lower logging levels to Verbose
  • Execute deployment
  • Revert to default logging levels

Download the full PowerShell script here.

Lower the logging levels to Verbose

Below you find a script which sets a predefined set of logging levels. This set can be used as a basic for every deployment or configuration change. It is not set in stone that this is all you need, please update it to fit your needs.

Set-SPLogLevel -identity 'Search:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Configuration' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Database' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Feature Infrastructure' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:General' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Timer' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Topology' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Upgrade' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:PowerShell' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Deployment' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Management' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Marketplace' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Application Authentication' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Authentication Authorization' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:CSOM' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:CSOM Api' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Hosting Quota Management' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Monitoring' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Auth' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Portal Server:Runtime' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Portal Server:Long Running Operation' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:General' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Setup and Upgrade' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Database' -EventSeverity Verbose -TraceSeverity Verbose

Revert back to the default logging levels

Revert the logging levels to the default, after executing the deployment or configuration changes.


PowerShell x64 vs x86: set execution policy when using Visual Studio post build events

Running PowerShell scripts in the Post build events within a Visual Studio project? Getting errors telling you “running scripts is disabled on this system”?

Visual Studio Output window showing PowerShell execution error

While working on Office 365 Developer Patterns and Practices (PnP) solution OfficeDevPnP.PowerShell Commands I had troubles with building my solution. Visual Studio uses PowerShell x86 in the background instead of my default PowerShell which uses the x64 version.

Check PowerShell version: x64 versus x86

By running the following you can check the current version. Download the PowerShell function from Check-PSVersion.ps1

function Check-PSVersion { if ([System.IntPtr]::Size -eq 4) { # When equal to 4, then x86 Write-Host "Running x86 PowerShell session" } else { # When equal to 8, then x64 Write-Host "Running x64 PowerShell session" } } Check-PSVersion

Where to find the PowerShell executable for both x64 and x86

The x64 version of PowerShell (Windows 8.1) can be found under:


The x86 version of PowerShell (Windows 8.1) can be found under:


Change execution policy to use PowerShell in Visual Studio

Now we know we have two versions of PowerShell we can change the execution policy for the x86 version of PowerShell. Start the "C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe" with “Run as administrator”. Now change the execution policy accordantly.

Set-ExecutionPolicy Unrestricted

Show storage overview for site-collections with PowerShell

PowerShell is very powerful and helps you to quickly get different views on your SharePoint environment. The Usage class can be used to retrieve Storage information for a particular site-collection. Combining this into a PowerShell script provides an overview of storage sizing for your personal storage sites (My Sites) for example.

In this example all My Sites are located within the namespace When querying the My Sites I’m using this as input. After the basic query I transform the output to get the report.

The first query can be used for the numbers based on megabytes (MB). I’m using the System.Math.Round() method to transform the output based on custom tables in PowerShell.

Get-SPSite -Limit ALL | ?{$_.Url -like "**"} | Format-Table Url, @{Expression={[math]::round($_.Usage.Storage/1MB, 3)};Label="Storage"} -AutoSize

The output is shown below.

PowerShell console, output storage query

When I change the formatting for better readability you get the following query. The column Storage is displayed based on string formatting.

Get-SPSite -Limit ALL | ?{$_.Url -like "**"} | Format-Table Url, @{Expression={($_.Usage.Storage/1MB).ToString("#,###.000 MB")};Label="Storage"} -AutoSize

This will impact the column Storage shown in the output below.

PowerShell console, output storage query with string Formatting

Enjoy! Have fun with PowerShell.

How to: Detect the installed SKU of SharePoint with PowerShell

Do you need to know which SharePoint SKU or edition is installed on your server? Are you sure your product is not running the trial version? Do you need SharePoint 2010/2013 SKU and/or patch level information from your customer or IT department? This article provides you an easy to use PowerShell script which checks the installed products on a server and outputs the version (patch level).

You can use the Get-SPEdition PowerShell script as is. Simply run the script or use the Functions and call Get-SPEdition. Using the PowerShell scripts results in the following output.

Windows PowerShell: out Get-SPEdition

The script reads the registry to retrieve the installed versions. This information is located in below the “HKLM:software\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\InstalledProducts” path. Every GUID represents a SKU.

$products = @{ "BEED1F75-C398-4447-AEF1-E66E1F0DF91E" = "SharePoint Foundation 2010"; "1328E89E-7EC8-4F7E-809E-7E945796E511" = "Search Server Express 2010"; "B2C0B444-3914-4ACB-A0B8-7CF50A8F7AA0" = "SharePoint Server 2010 Standard Trial"; "3FDFBCC8-B3E4-4482-91FA-122C6432805C" = "SharePoint Server 2010 Standard"; "88BED06D-8C6B-4E62-AB01-546D6005FE97" = "SharePoint Server 2010 Enterprise Trial"; "D5595F62-449B-4061-B0B2-0CBAD410BB51" = "SharePoint Server 2010 Enterprise"; "BC4C1C97-9013-4033-A0DD-9DC9E6D6C887" = "Search Server 2010 Trial"; "08460AA2-A176-442C-BDCA-26928704D80B" = "Search Server 2010"; "84902853-59F6-4B20-BC7C-DE4F419FEFAD" = "Project Server 2010 Trial"; "ED21638F-97FF-4A65-AD9B-6889B93065E2" = "Project Server 2010"; "926E4E17-087B-47D1-8BD7-91A394BC6196" = "Office Web Apps 2010"; "35466B1A-B17B-4DFB-A703-F74E2A1F5F5E" = "Project Server 2013"; "BC7BAF08-4D97-462C-8411-341052402E71" = "Project Server 2013 Preview"; "C5D855EE-F32B-4A1C-97A8-F0A28CE02F9C" = "SharePoint Server 2013"; "CBF97833-C73A-4BAF-9ED3-D47B3CFF51BE" = "SharePoint Server 2013 Preview"; "B7D84C2B-0754-49E4-B7BE-7EE321DCE0A9" = "SharePoint Server 2013 Enterprise"; "298A586A-E3C1-42F0-AFE0-4BCFDC2E7CD0" = "SharePoint Server 2013 Enterprise Preview"; "D6B57A0D-AE69-4A3E-B031-1F993EE52EDC" = "Microsoft Office Online"; "9FF54EBC-8C12-47D7-854F-3865D4BE8118" = "SharePoint Foundation 2013" } $registryPath = "HKLM:software\Microsoft\Shared Tools\Web Server Extensions\$((Get-SPFarm).BuildVersion.Major).0\WSS\InstalledProducts" Get-RegistryKeyPropertiesAndValues -path $registryPath | ForEach-Object { Write-Host "Installed product: $($products.Get_Item($_.value)) (SKU ID: $($_.value))" } Write-Host "Installed version: $((Get-SPFarm).BuildVersion)"

With a little help from the Scripting Guy (Ed Wilson) and two MSDN articles I build the script. Enjoy!

Download: Get-SPEdition.ps1


Merge log files when troubleshooting a multi server SharePoint farm

Even after working with SharePoint for a while you find new features. The Merge-SPLogFile cmdlet is one of them.

This cmdlet retrieves all ULS log entries from all servers in the farm and creates a one new log file. You can use the ULS viewer for further slicing and dicing the log file for more details.

Use the cmdlet with additional parameters, otherwise it could become a large operation resulting in a large file. Use like “Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -StartTime "06/09/2008 16:00" – EndTime "06/09/2008 16:15"” is very useful.

Very use full for troubleshooting! Why I’ve missed this one, I don’t know…

Developing hybrid SharePoint apps that run on-premise and in the cloud – ESPC 2014

My session at the European SharePoint Conference (#ESPC14) was around developing hybrid apps with the SharePoint App Model. Below you can find the slide deck and PowerShell scripts I used during the demo.

Before you start building hybrid apps who are depending on the authentication done by Azure Control Services (ACS) you need to setup a trust between your on-premise farm and ACS.

  1. Replace the default STS certificate and reboot machine afterwards (Replace-STSCertificate.ps1)
  2. Install Microsoft Online Services Sign-In Assistant for IT Professionals RTW (64-bit),
  3. Install Microsoft Online Services Module for Windows PowerShell (64-bit),
  4. Run script to connect on-premise SharePoint farm to ACS (Connect-SPFarmToAAD.ps1)

Some important side notes:

  • When replacing the STS certificate, all current trusts who are depending on the STS become invalid. Meaning you have to recreate your existing Trusted Security Token Issuers (Install-TrustedSecurityTokenIssuer.ps1 & Remove-TrustedSecurityTokenIssuer.ps1)
  • Ensure you are using the RTW version of Microsoft Online Services Sign-In Assistant instead of the BETA (which is linked in the TechNet article)

Download PowerShell scripts.

Scripts originate from How to: Use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site (, I don’t own the scripts but only provide them for easy of use.

Error installing SharePoint 2013 SP1 bits on Virtual Machine

As part of creating a developer virtual machine you need to install the SharePoint 2013 bits. Now with the release of Service Pack 1 you can install both SharePoint 2013 and Service Pack 1 in one run.

But when I installed the software bits an exception was raised.

Problem signature:
  Problem Event Name:    OfficeClassicSetup
  SETUP EXE VERSION:    15.0.4454.1000
  SETUP DLL VERSION:    15.0.4569.1503
  ERROR CODE:    1603
  MSI HRESULT:    Unspecified
  OS Version:    6.3.9600.
  Locale ID:    1043

After digging around on the internet and trying different solutions the failing of the installation seems to be related to the CPU count. After increasing the number of virtual processors on the VM to 2 processors and re-running the prerequisites installer and SharePoint 2013 installer everything worked like a charm.

Solution steps:

  1. Increase virtual processor count to at least 2
  2. Re-run SharePoint 2013 prerequisites installer
  3. Re-run SharePoint 2013 installer

Get every new post delivered to your Inbox.

Join 39 other followers