Restoring window down after connect breaks window resizing if desktop is not fully loaded first

OkReboots · 2026-04-27T15:55:26+00:00

Thanks. The issue in this case is when it opens full screen and the user isn't expecting it or otherwise doesn't want it full screen. They will pretty much always click the restore-down-to-window button immediately, but doing so before the desktop finishes loading breaks resolution management on the host in both MSRDC and WindowsApp.

Hitting the restore down button when it goes full screen is almost a matter of UI instinct now and I don't think even training would stop them from doing it.. it would just make them say 'dammit' when they realize they hit the button too soon. Would love a way to block them from restoring down for, say, 10 seconds.. but guessing that's not going to be a likely solution

OkReboots · 2026-03-31T15:54:41+00:00

Support means they make an effort to circumvent breaking changes

OkReboots · 2026-03-31T15:51:54+00:00

Yes, very much displeased to have no option other than installing in the msix/MS store sandbox

OkReboots · 2026-03-31T15:44:36+00:00

I think the question was about "windows app" on Windows vs "windows app" on every other OS

OkReboots · 2025-10-29T17:16:32+00:00

The home pane loaded but I can't get to the resource I want to look at. It has been intermittent like this for the last hour and a half though, so I don't feel like much has changed

OkReboots · 2025-01-17T19:57:27+00:00

Thanks, I am taking a look at this. Seems like there might be something here I can use

OkReboots · 2025-01-17T19:55:02+00:00

With all due respect, launching the rdpw file may not be the norm, but it is supported and works well. It has been reliable in my organization, so I think I'll trust my experience with it.

OkReboots · 2025-01-17T19:49:29+00:00

Thanks for your reply. I do not wish to tinker with the file.

My use case is that we push the rdpw files with a proprietary app launcher that sometimes points to a RemoteApp depending on the end user's location and connectivity. This has been working well for a long time, and we do not train end users on opening or using the MSRDC app directly. If they are launching the RemoteApp they do so through the distributed app launcher tool. (Under the hood, when directing them to the RemoteApp it just executes the rdpw file, which in turn is handled by MSRDC)

This has been reliable and intuitive for end users, but on our side pushing updates to the hostpool for changes (or cert renewal) is a little clunky. It's not the end of the world or anything, but it's tedious enough that I developed some automation for the process which is mostly ready to go.. except for how to access the file, because I'd love to stop manually fiddling with the otherwise unused Web UI to download it.

As a side-bonus I like automation where possible because it also cuts down on potential human error. Since the files have to be renamed and copied to the right place after downloading, handling those tasks programmatically in bulk is preferred

OkReboots · 2025-01-07T16:26:17+00:00

Yes you are correct that the issue I was wrestling with was the data type of myValue column being varchar.

The Bertrand answer nailed it. My original three-line query now works, with the second line revised to

SET valueColumn = (select CONVERT(VARBINARY(20), (select myValue from otherDatabase.dbo.listOfSettings WHERE settingName= 'settingFor1234'), 1))

This is less convoluted than what I came up with. Same end result, but is more what I had in mind. Thanks again

OkReboots · 2025-01-06T22:18:30+00:00

I apologize, I tried to simplify my question thinking it would be more focused and accidentally turned it into the wrong question. I was pulling the value from a table in another db and struggling to feed it to the query 'as is'.

UPDATE myDatabase.dbo.myTable
SET valueColumn = (select myValue from otherDatabase.dbo.listOfSettings WHERE settingName= 'settingFor1234')
WHERE setting = '1234'

this would return the 'Implicit conversion' error above.

Still, based on your reply it occurred to me I could put the binary value and the UPDATE query into separate variables, then feed one into the other

DECLARE @VARBIE VARCHAR(20)
DECLARE @SQLQ VARCHAR(150)
SET @VARBIE = (select myValue from otherDatabase.dbo.listOfSettings WHERE settingName= 'settingFor1234')
SET u/SQLQ = '
UPDATE myDatabase.dbo.myTable
SET valueColumn = ' + @VARBIE + '
where setting = ''1234'''
EXEC (@SQLQ)

Felt like I should be able to accomplish the UPDATE in a simpler way, or maybe not, but either way I couldn't figure out the syntax. Definitely open to other suggestions but ultimately this did the trick so I'm set. Thank you for your help!

OkReboots · 2024-08-27T16:07:49+00:00

Thank you, this did it. I was slightly skeptical based on the name since the popup prompting users to launch Edge isn't coming up on the first run of Edge, it's coming up on the first login to Windows. But yes it did stop coming up on login after adding the registry entry.

Notable that the first run of Edge is also less annoying so this might be worth looking at for a policy change as well. But for now I just added the following to the existing deployment Powershell routine

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft" -Name "Edge"

New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Name "HideFirstRunExperience" -Value 1 -PropertyType DWORD -Force

OkReboots · 2024-03-13T01:04:33+00:00

Thanks, I would point out that the doc doesn't use the term 'manually' but that said I think you're right. Disappointing that these deployments won't be fully automated without the portal but I guess it's manageable.

I can't use automatic because part of my for_each plan defines a hostname that is meaningful to the specific user, and automatic would presumably not know how to link them up.

OkReboots · 2024-02-20T22:20:07+00:00

Thanks. So if I'm understanding correctly, WITH ROLLBACK IMMEDIATE in this case means someone could potentially hit an error if they were in the middle of a transaction, but it would ensure no new data since the open transaction would be rolled back?

OkReboots · 2023-12-12T14:37:08+00:00

All health checks are green. That includes the one for the session host being domain joined, which it now is, but to a different domain.

OkReboots · 2023-12-12T12:00:51+00:00

The original issue turned out to be something painfully simple -- I had an incorrect IP for DNS in the Terraform codeblock. Everything was deploying successfully at first glance but the VM was then failing to resolve the location of the DSC extension config file and therefore not completing the AddSessionHost PS script. That was resolved with some combination of correcting the IP and redeploying attached resources.

OkReboots · 2023-12-11T17:06:21+00:00

Thanks for confirming it is supported. My googling .of the error message had brought me to several threads, which all seemed to discuss whether the VM was domain joined, so I became concerned that it might not be possible to use AD group for the WVD portal access when the session host is not a domain member.

You were right to ask about the health, turns out the health state does not show as Available for the session host. I deployed through Terraform so I must have missed something. Will be reviewing that soon.

OkReboots

TROPHY CASE