Office, and potentially other apps, can launch other apps ... like a browser

[Abel Espino]

Knowing that, at the end, RemoteApps still imply a remote desktop services session (which is jut not shown), I explored to see what happened while activating Office.

Well, it is quite understandable and expected that it will/may launch whatever the default browser is in the underlying VM, but I wonder if that could be potentially dangerours, I mean, the whole purpose of publishing a RemoteApp, is to ... well ... don't display the desktop, but if the RemoteApp can launch other dependent applications, without those being published, from the security standpoint, shouldn't be allowed.

Effectively, even though the Edge browser is not published as a RemoteApp, when Office requires it (when you click "see account") it just happily launches the browser as an additional RemoteApp, although the browser is not published as an allowed RemoteApp.

This might be a "corner case", I don't know, but if there are other cases in which web browsing navigation is allowed just because the allowed RemoteApp launches a browser, poses a security risk.

My 2 cents.

[#2]

@Abel Espino 

It is still the same Session Host as it has ever been, with same lockdown policies that can be applied. The technology running on top of Windows 10/ Windows Server isn't totally new. So old tricks will work here either - see and read about locking down RDSH hosts and apply proper settings that work for your org. Since WVD requires classic AD, you should be able to deploy required policies without troubles that prevent users from escaping their app. You can even go step further and lock it down with Applocker, which by the way you should. 

[#3]

@Aleksander Pawlak 

Of course I know the myriad of things you've to know/do as I've been dealing with this since TS and before, and it is precisely because of that experience, that I'm looking for ways to "break things", I'm quite familiar with all those nuances.

But as this thing is in Preview, and this (the fact that the "system" ... ok the client ... by itself is uncapable of doing that level of restriction) is an old and annoyng thing, I think it's a good oportunity for the developers and program managers to deal with that at this stage.

I mean, think for a moment, the "marketing" that points to sell the promise of forgetting about all the RDS stuff (Gateway, Broker, Licensing, SQL Server, only to mention software) is certainly an attractive for us who have dealt with this over almost two decades: that definitely is a good thing.

It is also a good thing for "newbies", but arguably, a newby will feel this (what is stated in the subject) as a "lame failure" ... why in the heaven that happens? ... well, then it goes ... duh ... "it is still an RDS Session, so the user still has access to whatever is available in his session", but still the fact that the client renders the unwanted/unallowed app, "should" be something that this "as a service" solution should abstract the administrator from.

Having to continue dealing with this, with this new solution, is a miss.

And yes, there might be other thousand things to think about ... but my point is:
Newby says: Really?, you publish an RemoteApp and it is able to launch other apps that aren't published just because it invoked it?, Really?
Experienced says: Really?, still having to deal with this?

Don't get me wrong, I've learned to love RDS, it's fed me but, that doesn't prevent me from making some constructive criticism.

[#4]

@Abel Espino 

For RDS admins WVD gives out of the box worries like Gateway management, certificates, high availability, SQL maintenance, configuration, MFA security and loads of other stuff. It is a selling point in itself already, even if locking down WVD is down to RDS admin. Many organizations will have an RDS GPO ready which can be applied to WVD with only minor tweaks, if any at all. 

Since we are trying to make a voice... From my point of view, I still find it a big burden of needing to have classic AD / AD DS installed. I wish MS priorities Windows Server managed by Intune + working AAD Join to Windows Servers. Classic AD has been a good technology, it still is, but it has it's age already. There are steps in progress for that, like Windows Hello over RDP and Windows Server can already be joined to AAD in limited way, but its far from there yet to hold a serious production case :)

[#5]

@Abel Espino 

I agree.

If you have Office on your session hosts, Teams will also pop up every time you start any remoteapp, if you havent hacked the installer or made GPOs to prevent Teams from starting in the first place.

And yes, they are hacks, because it should have been much easier to set global settings for Teams in the installer (and not having to spend an hour reading about different approaches and hundreds of people scratching their heads).

Its like adware, just shows up whether you want it to or not. And when I start a completely different remoteapp, and Teams is not published, I dont expect Teams to start.

This disallows using the same session hosts for remote desktop and remoteapps, so we need to have more host pools and application groups so we can make these hacked versions behave like we want them to.

And I agree, for those of us who don't have much experience dealing with RDS or TS, we don't really expect having to read about all the dark corners of the old system, when dealing with what is presented as the new cloud based first class citizen solution.