May 032021
 

So you’re looking at deploying Microsoft Teams for your Horizon View VDI deployment.

This guide will allow you to deploy Microsoft Teams Optimization for Manual Pools, Automated Pools, and Instant Clone Pools, for use with both persistent and non-persistent VDI. This guide will NOT provide instructions on deploying Microsoft Teams inside of non-persistent VDI or Instant Clones (stay tuned for a guide for that soon).

Please make sure to check out Microsoft’s documentation on “Teams for Virtualized Desktop Infrastructure“, and VMware’s document “Microsoft Teams Optimization with VMware Horizon” for more information.

Requirements

To get started, you’ll need the following:

  • Microsoft Teams MSI Installer (Available here: 64-Bit, 32-Bit)
  • VMware Horizon Client (Available here)
  • VDI Desktop or VDI Base Image
  • Ability to create and/or modify GPOs on domain
  • VMware Horizon GPO Bundle

Background

Before Microsoft Teams VDI Optimization, VMware’s RTAV (Real-Time Audio-Video) was generally used. This offloaded audio and video to the VMware Horizon Client utilizing a dedicated channel over the connection to optimize the data exchange. With minor tweaks (check out my post on enhancing RTAV webcam with VMware Horizon), this actually worked quite well with the exception of microphone quality on the end-users side, and high bandwidth requirements.

Starting with Horizon View 7.13 and Horizon View 8 (2006), VMware Horizon now supports Microsoft Teams Optimization. This technology offloads the Teams call directly to the endpoint (or client device), essentially drawing over the VDI VM’s Teams visual interface and not involving the VDI Virtual Machine at all. The client application (or thin client) handles this and connects directly to the internet for the Teams Call. One less hop for data, one less processing point, and one less load off your server infrastructure.

Microsoft Teams Optimization uses WebRTC to function.

Deploying Microsoft Teams Optimization on VMware Horizon VDI

There are two components required to deploy Microsoft Teams Optimization for VDI.

  • Microsoft Specific Setup and Configuration of Microsoft Teams
  • VMware Specific Setup and Configuration for Microsoft Teams

We’ll cover both in this blog post.

Microsoft Specific Setup and Configuration of Microsoft Teams Optimization

First and foremost, do NOT bundle the Microsoft Teams install with your Microsoft 365 (Office 365) deployment, they should be installed separately.

We’re going to be installing Microsoft Teams using the “per-machine” method, where it’s installed in the Program Files of the OS, instead of the usual “per-user” install where it’s installed in the user “AppData” folder.

Non-persistent (Instant Clones) VDI requires Microsoft Teams to be installed “Per-Machine”, whereas persistent VDI can use both “Per-Machine” and “Per-User” for Teams. I use the “Per-Machine” for almost all VDI deployments. This allows you to manage versions utilizing MSIs and GPOs.

Please Note that when using “Per-Machine”, automatic updates are disabled. In order to upgrade Teams, you’ll need to re-install the newer version. Take this in to account when planning your deployment.

For Teams Optimization to work, your endpoints and/or clients MUST have internet access.

Let’s Install Microsoft Teams (VDI Optimized)

For Per-Machine (Non-Persistent & Persistent) Install, use the following command:

msiexec /i C:\Location\Teams_windows_x64.msi ALLUSER=1 ALLUSERS=1

For Per-User (Persistent VDI) Install, you can use the following command:

msiexec /i C:\Location\Teams_windows_x64.msi ALLUSERS=1

If in the event you need to uninstall Microsoft Teams to deploy an upgrade, you can use the following command:

msiexec /passive /x C:\Location\Teams_windows_x64.msi

And that’s it for the Microsoft Specific side of things!

VMware Specific Setup and Configuration for Microsoft Teams Optimization

When it comes to the VMware Specific Setup and Configuration for Microsoft Teams Optimization, it’s a little bit more complex.

VMware Horizon Client Installation

When installing the VMware Horizon Client, the Microsoft Teams optimization feature should be installed by default. However, doing a custom install, make sure that “Media Optimization for Microsoft Teams” is enabled (as per the screenshot below):

Screenshot of VMware View Client Install with Microsoft Teams Optimization
VMware View Client Install with Microsoft Teams Optimization

Group Policy Object to enable WebRTC and Microsoft Teams Optimization

You’ll only want to configure GPOs for those users and sessions where you plan on actually utilizing Microsoft Teams Optimization. Do not apply these GPOs to endpoints where you wish to use RTAV and don’t want to use Teams optimization, as it will enforce some limitations that come with the technology (explained in Microsoft’s documentation).

We’ll need to enable VMware HTML5 Features and Microsoft Teams Optimization (WebRTC) inside of Group Policy. Head over and open your existing VDI GPO or create a new GPO. You’ll need to make sure you’ve installed the latest VMware Horizon GPO Bundle. There are two switches we need to set to “Enabled”.

Expand the following, and set “Enable HTML5 Features” to “Enabled”:

Computer Configuration -> Policies -> Administrative Templates -> VMware View Agent Configuration -> VMware HTML5 Features -> Enable VMware HTML5 Features

Next, we’ll set “Enable Media Optimization for Microsoft Teams” to “Enabled”. You’ll find it in the following:

Computer Configuration -> Policies -> Administrative Templates -> VMware View Agent Configuration -> VMware HTML5 Features -> VMware WebRTC Redirection Features -> Enable Media Optimization for Microsoft Teams

And that’s it, you’re GPOs are now configured.

If you’re running a persistent desktop, run “gpupdate /force” in an elevated command prompt to grab the updated GPOs. If you’re running a non-persistent desktop pool, you’ll need to push the base image snapshot again so your instant clones will have the latest GPOs.

Confirming Microsoft Teams Optimization for VDI

There’s a simple and easy way to test if you’re currently running Microsoft Teams Optimized for VDI.

  1. Open Microsoft Teams
  2. Click on your Profile Picture to the right of your Company Name
  3. Expand “About”, and select “Version”
Screenshot of Microsoft Teams - About and Version to check Teams Optimization for VDI
Microsoft Teams – About and Version to check Teams Optimization for VDI

After selecting this, you’ll see a toolbar appear horizontally underneath the search, company name, and your profile picture with some information. Please see the below examples to determine if you’re running in 1 of 3 modes.

The following indicates that Microsoft Teams is running in normal mode (VDI Teams Optimization is Disabled). If you have configured VMware RTAV, then it will be using RTAV.

Screenshot indicator of Microsoft Teams VDI Optimization disabled
Microsoft Teams VDI Optimization disabled

The following indicates that Microsoft Teams is running in VDI Optimized mode (VDI Teams Optimization is Enabled showing “VMware Media Optimized”).

Screenshot indicator of Microsoft Teams VDI Optimization enabled
Microsoft Teams VDI Optimization enabled

The following indicates that Microsoft Teams is configured for VDI Optimization, however is not functioning and running in fallback mode. If you have VMware RTAV configured, it will be falling back to using RTAV. (VDI Teams Optimization is Enabled but not working showing “VMware Media Not Connected”, and is using RTAV if configured).

Screenshot of Microsoft Teams VDI Optimization Fallback
Microsoft Teams VDI Optimization Fallback

If you’re having issues or experiencing unexpected results, please go back and check your work. You may also want to review Microsoft’s and VMware’s documentation.

Conclusion

This guide should get you up and running quickly with Microsoft Teams Optimization for VDI. I’d recommend taking the time to read both VMware’s and Microsoft’s documentation to fully understand the technology, limitations, and other configurables that you can use and fine-tune your VDI deployment.

Mar 302020
 
Office 365 Logo

Once you deploy Remote Desktop Services (RDS) for employee remote access, your next step will be to install user applications as well as all your line of business applications.

One of the most widely used applications suite is Microsoft Office, particularly Microsoft Office 365.

In order to deploy Microsoft Office 365 in a Remote Desktop Services environment, a number of requirements must be met. There is also special instructions which must be followed to properly deploy it.

This information is applies to when you want to install Office 365 / Microsoft 365 to a shared virtual machine, or a golden image for VDI.

What’s required

To deploy Microsoft Office 365 on a Remote Desktop Services Server, you’ll need:

  • A Remote Desktop Services Server (Configured and Running)
  • Microsoft 365 Apps for Enterprise (formerly named as Office 365 ProPlus)

Licensing

Special attention must be paid to licensing. In order to properly license and activate Office 365, you’ll need one of the following products that supports Shared Computer Activation:

  • Microsoft 365 Apps for Enterprise (formerly known as Office 365 ProPlus)
  • Office 365 E3
  • Office 365 E5
  • Microsoft 365 Business Premium

All 4 of these products include and support “Shared Computer Activation“.

Microsoft 365 Standard, Office 365 Business, Office 365 Business Premium, and Office 365 Business Essentials cannot be used as they do not include or support Shared Computer Activation.

An exception is made for Microsoft 365 Business Premium which actually includes Microsoft 365 Apps for Business, but doesn’t support enabling “Shared Computer Activation” via Group Policy Objects and must be done using the XML configuration file method.

Installing Office 365

Once you have the proper licensing and you’re ready to proceed, you can start!

  1. First you’ll need to download the Office Deployment Tool from this link: https://go.microsoft.com/fwlink/p/?LinkID=626065. You save this wherever.
  2. Create a directory that you can work in and store the Office 365 installation files.
  3. Open the file you downloaded from the Microsoft Download site, extract the files in to the working directory you created in step 2.
  4. Open a Command Prompt, and change in to that working directory.
  5. We’re now going to run the tool and download the x64 image using the xml that was extracted by running the following command:
    setup.exe /download configuration-Office365-x64.xml
    To download the 32-bit version or enterprise version, use one of the other xml files that are in the directory.
  6. There will be no output and it will take a while so be patient.
  7. Now we want to open the xml file we previously used (in our case “configuration-Office365-x64.xml”) and add the following lines to the file right above the final line (right above </Configuration>):
    <Display Level="None" AcceptEULA="True" />
    <Property Name="SharedComputerLicensing" Value="1" />
    These variables enable Shared Computer Activation and disable automatic activation. Save the file.
  8. We can now install Office 365 by running the following command:
    setup.exe /configure configuration-Office365-x64.xml

Office 365 should now install silently, and then afterwards you should be good to go!

When a user logs in for the first time it will ask them to activate on their account. The user must have a license attached to their Office 365 account.

For more information and advanced settings, you can see the Microsoft guide here: https://docs.microsoft.com/en-us/deployoffice/deploy-office-365-proplus-by-using-remote-desktop-services.

Let me know if it worked for you, leave a comment!

Aug 202018
 

An all too common problem is when users report e-mail delays ranging from 5 to 15 minutes. When troubleshing these types of issues, you’ll notice this commonly occurs when receiving e-mails from organizations that use Office 365. Specifically this occurs due to greylisting.

Why does this happen

You’re organization is using greylisting on your e-mail proxy/SMTP relay to reduce spam. Greylisting temporarily rejects the first send of an e-mail and waits for the sending server to re-transmit the message. This process usually takes around 5-15 minutes to complete. Greylisting is used because spammers won’t re-transmit the message, which leads to a massive reduction of spam messages coming through.

Once the sending server retransmits, the sending server IP address is added to your firewalls “safe senders” whitelist. From this point on the IP address (or server) will not be subject to greylisting (and any subsequent e-mails).

Office 365 has hundreds, if not thousands (possibly 10’s of thousands) of servers they use to transmit e-mail. The chance of multiple e-mails being sent from a single server is very slim, therefor greylisting is applied to every IP (server) that is sending e-mail because it’s different. Each e-mail from an Office 365 user can take 5-15 minutes, since a new server is used every time.

How to resolve

You’ll need to configure and add an exception to your e-mail proxy/SMTP relay/firewall. This exception can be based off domain, DNS name of sending server, or IP address ranges.

Scroll down for instructions on how to create an exception on a Sophos UTM.

Domain Exception

If you use domain based exceptions, you’ll need to configure these manually for each sending domain that you want your firewall to skip greylist checking. This is a very manual process, which requires lots of human intervention to continuously update your greylist exception.

DNS FQDN of MX Server

This method is the easiest, however most firewall or UTM’s will now allow these types of exceptions since a number of DNS queries will be needed everytime an e-mail comes in. One DNS query on the MX record, and then another DNS query on the DNS host contained in the MX record. If you can configure this type of exception, you’ll want to configure it as below:

*-com.mail.protection.outlook.com

IP Address Range

This is the best method. To create an IP address range exception, we’ll need a copy of all the IP address ranges or IP address spaces that Office 365 uses to send mail. This list can be found at: https://docs.microsoft.com/en-us/office365/SecurityCompliance/eop/exchange-online-protection-ip-addresses.

We’ll need to create an exception that skips greylist checking on the IP addresses outlined in the above link. This will stop any greylist checking on e-mails from Office 365 servers.

In my case, I use a Sophos UTM firewall, and to create an exception I had to do the following:

  1. Log on to the Webmin interface.
  2. Select “Email Protection”, then “STMP” on the left hand side, then “Exceptions” tab at the top.

    Sophos UTM E-Mail and SMTP Exception List

    Sophos UTM E-Mail and SMTP Exception List

  3. Create a “New Exception List” and call it “Office 365 GreylistWhitelist”.
  4. Check the “Greylisting” box under “Antispam”, and then check the “For these source hosts/networks”.

    Sophos UTM SMTP Create Exception

    Sophos UTM SMTP Create Exception

  5. Click the “+” button, and call the Network Definition “Exchange365-EOP-Group”. Change the type to “Network Group”.
  6. Click the “+” button in the members section, and start adding the IP spaces. Repeat this for each IP space (in total I added 23). Each network name (IP address space) requires a unique name, I named mine “Exchange365-EOP1” through “Exchange365-EOP23”.

    Sophos UTM SMTP Configure Exception

    Sophos UTM SMTP Configure Exception

  7. Click Save on the Network Group, and click Save on the exception.
  8. Enable the Exception

    Sophos UTM SMTP Exception Rule

    Sophos UTM SMTP Exception Rule

  9. Completed! You’ve now made the exception and delays should no longer occur.
Jan 142018
 

The Problem

In the latest updates and versions of Microsoft Office 2016, I found a bug where when a user adds a new on-premise Microsoft Exchange 2016 account, it will repeatedly prompt for a username and password and ultimately fail if you hit cancel (no matter how many times you enter credentials). This was on the internal LAN on a domain joined workstation.

I did the usual checks:

  • Check Virtualdirectory configuration on Exchange
  • Check Virtualdirectory configuration on IIS (Internet Information Services)
  • Check Autodiscover DNS entries, InternalURL and ExternalURL configuration
  • Check for SCP inside of domain

All the of the above came back fine and were configured properly.

I have numerous other Outlook 2016 clients configured and working (installed as older versions, but have been updated), so I used those to troubleshoot (same scenario, domain joined on internal LAN and external WAN). After spending 10 hours ripping apart everything, confirming configuration, I noticed that when using the “Test Email Autoconfiguration…” (holding CTRL while right clicking on Outlook tray icon), that the e-mail clients had a skewed order for checking autodiscovery.

The e-mail clients were actually trying to authenticate with Office365 before my own on-premise Exchange Server (domain SCP or autodiscover records). This is absolutely bizarre! After spending 2 hours googling (I couldn’t find anything), I finally stumbled across this document and found an interesting piece of information:

https://support.microsoft.com/en-ca/help/3211279/outlook-2016-implementation-of-autodiscover

“Outlook uses a set of heuristics to determine whether the user account provided comes from Office 365. If Outlook determines confidently that you are an O365 user, a try is made to retrieve the Autodiscover payload from the known O365 endpoints (typically https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml or https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). If this step does not retrieve a payload, Outlook moves to step 5.”

WTF?!?!?

So while this doesn’t explain why this happened, it explains what’s happening. I believe this is what’s happening as my working clients are trying to Autodisocver with Office365 first…

I went ahead an created a registry value to control the policy for “ExcludeExplicitO365Endpoint“. After configuring the registry key, I noticed that Autodiscover was now functioning properly and checking SCP and autodiscover DNS records first. I have no idea why the “heuristics” determined I was an Office365 user, but I’m not (I do have access to Office365 as a partner, but don’t use it and don’t have it configured). This may effect other partners, or users that utilize some O365 services…

The Fix

To fix this issue, create a text file and copy/paste this text below.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Then save it, and rename it as ExcludeExplicitO365Endpoint.reg and run it (this will import the applicable registry key). ONLY DO THIS if you are using an Exchange On-Premise account, and not a Office365 or hosted exchange account.

Keep in mind that autodiscover also queries the domain root (domain.com), before querying the autodiscover host (autodiscover.domain.com). If you want to stop both the Office365 autodiscover and the root domain autodiscover challenge, use the following below:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001

You’ll notice that we also set “ExcludeHttpsRootDomain” to “1” which stops it from checking the root domain.

After this, the issue was completely fixed. If you know what you’re doing, you can also use Outlook GPO settings and deploy this to a vast number of systems using Group Policy.

Additional Note (added November 2nd, 2018)

While reading numerous documents covering autodiscovery, I also came across an article that went in to detail with particulars as to how Mapi over HTTP functions. Even with the above, when accessing Outlook externall from the domain, you may still notice a single password prompt for the first time you log in externally.

After reading through documentation, I found that this is most likely because the first user account login (the very first time the user logged in on the computer), the username format of “DOMAIN\Username” was used, and not the UPN. The documentation mentioned that this may fail the negotiation, which will require a single password prompt on autodiscovery. This issue can be avoided by using the users UPN ([email protected]) to log in for the first time on the system.

Please note that the UPN must match the user’s e-mail address.