Whoomp, there it is: guest access for MS Teams!

It’s been a long awaited feature for the app that should be Microsoft’s answer to Slack: collaborating with users from outside your organization in Teams. While the feature has been announced earlier, it has been postponed moments before it’s initial launch date. But it’s finaly here: in this blogpost the general manager for Teams announces guest access for Teams.

Of course, for an app that aims at facilitating collaboration and fighting shadow IT, when rolling out externa access security should be a big priority. Microsoft accomplished this by leveraging Azure AD B2B Colloboration. This enables, for example, conditional access policies to be applied to guest accounts.

Along with this major feature, new developer tools for MS Teams have been announced on the MS Dev Blog.

Dupsug Basics – Part Deux

Op 19 september 2017 organiseert de Dutch Powershell User Group weer een ‘DuPSUG Basics’ event. Op 22 maart vorig jaar was de eerste keer dat er zo’n dag georganiseerd werd. Deze zeer goed bezochte editie smaakte waarschijnlijk naar meer, want er wordt nog regelmatig gevraagd wanneer de tweede editie gehouden wordt. Op Prinsjesdag, dus!

In totaal zijn er op deze dag 7 sessies van zeven verschillende sprekers (waaronder twee MVP’s) over uiteenlopende onderwerpen, zoals SQL en Office 365. Ikzelf zal de sessie ‘Powershell for Office 365 Administrators’ verzorgen. Het volledige tijdschema is als volgt:

Tijdstip Spreker Onderwerp
9:00 Welkom.
9:15 – 10:30 Mark van de Waarsenburg Powershell basis.
10:30 – 10:40 Koffie
10:40 – 11:25 Erik Heeres Powershell Remoting.
11:30 – 12:15 Jaap Brasser [MVP] Manage your infrastructure with PowerShell.
12:15 – 13:15 Lunch
13:15 – 14:00 Robert Prust Improving your scripts.
14:00 – 14:45 Sander Stad DBAtools – PowerShell and SQL Server Working Together.
14:45 – 15:00 koffie
15:20 – 16:05 Ralph Eckhard Powershell for Office 365 Administrators.
16:10 – 16:45 Jeff Wouters [MVP] Tips and tricks.

Meer info, of (gratis!) kaarten bestellen? Ga naar http://dupsug.com/2017/07/14/dupsug-presents-dupsug-basics-part-deux/. Wees snel, want er zijn niet veel kaarten meer beschikbaar!

Getting VPN logging from Azure

Today, I was working with a customer who had some issues with a VPN connection from Azure to his on-premises environment. After checking the configuration, everything seemed to be okay. I decided to run some logging on the VPN connection from the Azure side, to see if I could pin-point the issue. For that, I usually use the following script, of course after logging in to Azure in Powershell using add-azureaccount:

This script prompts to select your Azure Subscription, Storage Account and vNet, and then starts 300 seconds of logging on the vNetGateway in that vNet, writing the output of these logs to the Storage Account you specified.

However, when the start-azurevnetgatewaydiagnostics cmdlet was run, I received an error that the StorageContext could not be read. After some Google searches, I found out I was running in to this issue. As discussed there, uninstalling the Azure module and reinstalling it using the 3.8.0 version solved my issue and I could start the logging.

Once done, you can retrieve the logged data using the following code:

In my case, it turned out there was a mismatch in the preshared key between the Azure side of the VPN connection and the on-premises firewall.

If you want to retrieve the PSK’s of all VPN’s in a specific vNet, you can do that using PowerShell.

This prompts for your subscription and vNet name, and outputs the PSK’s of all VPN’s in that vNet.

OneDrive Files on Demand: the new OneDrive experience

One of the things I’m looking forward to in the new Windows 10 Creators Fall update is the new OneDrive sync-client, which enables the files on demand functionality. In fact, I’m looking forward to it that much, I decided to enroll my device in the Windows 10 Insiders Fast Ring, so I could take the new client to a test drive right now.

So, here it is! Right after finishing the upgrade and logging in, I’m greeted by the welcome screen of the new sync client.

The three icons in the welcome screen explain nicely how files on demand works: you can choose to have the file in the cloud only (without syncing it to the device), to have the file available in the cloud ánd on the device, where the client decides what files are actually being synced, or to have the file always being synced to the device, whether or not it is being used.

So, how does this work out in practice?

This is the view of my OneDrive folder. Please note I did some editing to protect the privacy of some of my clients 😉 The view in Windows Explorer for the OneDrive folder is the same as I’m used to. The only thing that changed, is the icon next to the folder, indicating the status of the folder.

Navigating in to the folder, we see the same icons. In this case, some files have been marked to use only in the cloud, or to always keep on the device. This can be done by right clicking on the file and selecting the appropriate option in the context menu.

So, where is the use in this? For starters, it allows you to sync only specific files to your device, which makes sure you don’t run in to problems with the capacity of your disks. In my case, the Surface Pro 4 I ran this test on has a 256GB SSD-disk in it, where Office 365 gives me 1TB of personal storage in OneDrive. That won’t fit 😉 Second of all, when you choose to keep a file only in the cloud, the file is still visible in your normal explorer view. You can select it, upload it from a browser context menu, do everything you would normaly do with it. When you actually ‘open’ the file, it’s pulled in from the cloud to be used. This greatly enhances the user experience!

So, can you see how much space this saves you? Of course you can 😉 At first, I checked it with just one file. Note the difference between the ‘size’ and ‘size on disk’ info.

After some manual checking on which files I don’t need to be available offline, I managed to really save some space on my device.

Of course, your mileage may vary depending on what sort of files you store in your OneDrive and what you need to be available offline, but the OneDrive team managed to greatly enhance the experience! Coming soon to Windows 10 computers near you 😉

Exchange Cached mode in RDS/VDI

Today I found myself, again, working with a customer that complained of poor performance in Outlook in combination with Office 365 (Exchange Online) on an environment using RDS. The main complaint is Outlook is slow when switching between folders, opening shared mailbox or using different calendars.

The reason for these issues is simple: when moving from Exchange on-prem to the cloud, the network latency between the clients and the Exchange-server increases and every glitch in the network becomes noticeable. When using ‘fat clients’, you can make sure Outlook is running in ‘cached mode’, so you work from your local .ost-file that syncs with the Exchange servers, thus eliminating most network issues. In RDS (or VDI, for that matter) setups, this isn’t always an option. So how to fix these issues?

First of all, you need to make sure you environment is set up in the best possible way. This TechNet blog can help you optimize and troubleshoot your Office 365 network connectivity. Especially the DNS-settings mentioned in the blogpost can be a culprit. Make sure you use DNS servers in the same geographical location as you RDS/VDI servers, so you get redirected to the right Exhange Online servers in the Azure network. More good pointers on optimizing network performance can be found here.

If all this is okay, you can use cached mode on your RDS/VDI environment. Default, the .ost file generated when using cached mode will be placed in the appdata\local directory, which causes it to not be included in roaming profiles or folder redirection. This way, when you log on to your RDS farm and are being redirected to a new server, your local cache will need to be rebuild. You can avoid this by redirecting the .ost file to a network share using a group policy. Please be aware, that previously this wasn’t a supported environment. However, with modern Outlook clients (specifically Outlook 2010 and above) this is supported. You can find detailed information here, but to summarize: if you use a high-speed, low latency network connection between your Outlook client and the file server, are using Server 2008 R2 or higher for your RDS/VDI and make sure there is ‘single file access’ to the ost-files (in other words: only one process (or user session) will access the ost-file at the same time), you are good to go.

Be aware that redirecting the .ost file does have some impact on search functionality in Outlook. The search is based on indexing by the Windows Search Service, which runs on the client computer. This means that when you are redirected to a different server, search may not be (completely) available within Outlook due the ost-file being re-indexed. Also, you need to plan you deployment and make sure you have enough disk space and disk I/O to serve the OST-files.

As you can see, these performance issues probably need to be fixed within the Outlook client. Until that happens, using cached mode can be a alternative to improve performance, although it does have some side-effects.

Of course, investing in an ExpressRoute connection, and realizing a low-latency connection to Office 365, could also solve (at least some of) these issues. However, if you would like to use ExpressRoute to connect to Office 365 you would need the premium plan which isn’t cheep.

For me, running cached mode in RDS/VDI with a limit of 6 months to cache offline seems to work OK, but you’ll have to learn how to live with the drawbacks.

Azure AD Group Based Licensing

When working with larger Office 365 and / or EM+S deployments, one of the pains for me has always been the automation of license assignment. You can provision users in Azure AD (and thus in Office 365) automatically using Azure AD Connect, and you could even add some magic with some PowerShell scripts to assign a license to these users based on OU or group-membership in your on-prem AD. The removal of these licenses takes even more scripting, where you would need to compare you on-prem group membership with the active licenses and remove licenses when needed.

About two weeks ago, Microsoft announced something to fill this gap: Azure AD Group based licensing. Currently, this feature is available in public preview. While in preview, you’ll need a paid Azure AD subscription to use the feature, like the one included in EM+S. Just a plain Office 365 tenant won’t be sufficient. When the feature hits GA, this prerequisite will be lifted.

Using the feature is as simpel as it sounds. From the (new) Azure Portal, you navigate to the Azure AD resource and click the ‘licensing’ tab. From there, you can navigate to all the licenses that are available in your environment.

By clicking through to one of the available licenses, you get the option to assign this license to a group.

All Microsoft Online services that require user-based licensing are supported and are displayed in this pane.

When selecting the ‘groups’ option, you can select the group to assign this license to. and search for the group you would like to use. This group can live solely in Azure AD, or can be a security group synced from you on-prem AD.


You can specify which parts of the license you would like to assign, you can create a pretty fine-grained solution using various groups to enable or disable specific features.

All in all, this is a pretty neat solution to provide some ease in managing user licenses for Microsoft Online services.

There is some good documentation on this feature on the Microsoft website. Of course, as is a feature that’s currently in public preview, there are some known issues and limitation, which are also pretty well documented.

For me, I can’t wait to get this feature implemented at some of the larger tenants I manage, to ease the administrative tasks of on- and offboarding users.

365Tools is in the Powershell gallery

After my previous post about my ‘open-msolconnection’ function, I decided that it would be nice if I grouped all my commonly used PowerShell scripts for managing Office 365 in a single module, so I could publish it to the PowerShell gallery… So here it is!

As of today, the 365Tools module is available from the Powershell Gallery. Of course, I’ve also created a GitHub repo for maintaining the whole thing.

Currently, the module just includes the open-msolconnection function and a function I use for reporting on mailbox sizes, licensing status, etc.

You can install the module directly from the gallery by using one simple line of code:

After that, you can see the commands that are made available through the function:

Enjoy 🙂 If you have any issues or questions regarding the module, please leave a reply to this blogpost.

Connect to O365 Powershell with one command

For a few years, I’ve been using a simple script to connect to Office 365 using Powershell. In stead of typing all the commands needed to connect to both Azure AD and Exchange Online, I use a small piece of code placed in my Powershell profile to do all this for me. I simply type open-msolconnection from my Powershell prompt, specify my username and password and that’s it.

I’ve received some questions about this little function, so I decided to share it on GitHub. You can find it here. Enjoy!