Teams and Remote Desktop Services / Azure WVD

With the year of the pandemic behind us, we find ourselves in a “do we stay or do we go” situation with work. WFH has its own set of challenges and many companies found variations of remote desktop solutions to help bridge the gap. During this same time, many companies found huge advantages of Microsoft Teams and began the widespread deployment of the UC solution to again, help bridge the gap. However, these two technologies do not happily co-exist in nearly all situations.

Microsoft has clearly defined two separate remote solutions and what they offer - VDI and RDS. When you think of VDI you may recall the days when “dumb terminals” were connected to a backend and really presented a limited and specific solution. When working with VDI, from the terminals to the backend OS and configuration, all are specifically configured and laid out. These specific requirements allowed for an optimized and controlled environment. It is these same requirements that allowed vendors, such as Microsoft, to create solutions that were custom and known to work. In the VDI link below, this is the exact case Microsoft has described. When VDI is in play, Microsoft Teams and media can work. That means audio and video have a path to function as if you were running a local computer with Microsoft Teams - powerful but finite and generally limited to on premises solutions.

Teams for Virtualized Desktop Infrastructure - Microsoft Teams | Microsoft Docs

Remote Desktop Services - or RDS - is something entirely different. Technically when any IT administrator uses mstsc.exe to remote to a server, they are using Remote Desktop. Prior to the pandemic, I was already working with multiple clients who were looking for the best method to allow users to work remotely. A Terminal Server Farm / RDS Farm provides a great solution for many. In the past, it was not uncommon for enterprises to invest in 3rd party RDS solutions for their management such as Citrix. However, since Server 2016 Microsoft has invested heavily in the TS Farm solution allowing enterprises to go ‘native Microsoft’ in many instances. I can say with certainty those clients that had such a solution were ecstatic they had RDS solutions in place (99% of them utilizing Microsoft’s Remote Desktop Gateway as well) allowing everyone who was immediately pushed to WFH to be able to access corporate resources securely and effortlessly.

This was all great until an update was pushed to the TS servers for Microsoft Office 365 that included Microsoft Teams. This prompted all users to be logged into Teams and, no fault of their own, assume it should function. As the below link spells out clearly, RDS does not and cannot provide the media services one is looking for when working with real-time communications. This means all audio and video calls were not only not supposed to work but if they tried, the experience was awful. As anyone who works or assists with help desks knows, large impactful events are never a great morning with tons of calls/emails/tickets being created from all employees nearly all at once.

The end option - well there is always “user training” however relying on end users is generally a losing battle. So, using technology to resolve this issue we have two choices - sometimes forced upon us. 1) remove Teams from the RDS environment or 2) remove A/V functionality from Teams. #2 is rarely the correct solution and in all my clients’ environments, #1 is what we ended up doing. However, each organization is unique as are the end users, so that decision will be a personal one.

Use Teams with remote desktop services - Microsoft Teams | Microsoft Docs

The key to remember is there are 3 high-level modalities in Microsoft Teams:

Instant Messaging/Presence
Collaboration
Audio/Video

Meetings is a combo of collab and A/V, but the takeaway is A/V is NOT supported in RDS and only in VDI. All other basic features work in both worlds. Remember this when deploying your remote WFH scenarios and Teams will work for you and not against you.

-Brian R. Ricks/March 29, 2021


vCenter 6.7 and SCVMM 2019 UR2

I had been anxiously awaiting for the UR2 code to be released last year to finally integrate my VMware environment back into SCVMM only to find when it was released, I was unable to get it to work. My general error was it was not able to grab the certificate. Manually running Get-SCCertificate threw the same error.

Months later I decided to look at this again and I still had the same issue. I started troubleshooting by capturing Wireshark traces on the vCenter and SCVMM box to see if they were even talking. They were, but the communication would come in with a Client Hello and then an immediate FIN, ACK. So the vCenter box was refusing communication.

I noticed the communication from SCVMM was TLS 1.0 (lame) and checking docs from VMware, 6.7 ONLY talks TLS 1.2. Both my servers were Windows Server 2016 so they wanted to do TLS 1.2 but were not forced. Well - if the app wasn’t going to negotiate the communication, I figured I would force the communication to TLS 1.2. Simple registry entries to disable the older protocols and enforce TLS 1.2 along with strong .NET communications and a reboot was all that was needed. I have included my version of the disabling the old, enforcing the new below. Simply download or save as a DisableSSL2-TLS11.reg and run on the servers in the communication path.

-Brian R. Ricks/February 3, 2021


Microsoft Ignite 2019 Community Reporter Interview: Brian Ricks

https://www.youtube.com/watch?v=p8LE9ieRb2g


Microsoft End of Support 2019

As with all software, there comes a time when the software is no longer supported. There are MANY who complain about this in the Microsoft ecosystem which I find sad since 10 years is a pretty long time. For those that have old 2008 R2 boxes still in production and Windows 7, your time has come.

What does this mean to you as a user? It is not that the software will stop working. New features and upgrades have been gone for 5 years, so it is not that either. No, it is all about security and vulnerabilities. With the end of extended support all those machines that are unsupported will no longer receive (i.e. they are no longer being created) security updates. That means when a vulnerability is exposed - and there will be - the systems will not be patched. There are SCADA-type systems that could care less since they are off-net but I would bet you know of at least one server or PC that is no longer supported that is still on the network.

Reach out if assistance is needed and, in some cases, Microsoft has resources to assist. Microsoft was also kind enough to provide the following table (thank you Greg Taylor from the Exchange team) to help those plan (or react as the case may be)

-Brian R. Ricks/February 3, 2021