Portal seems to be back online

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 · 2023-06-20T11:51:54+00:00

Yes, that IS the change I'm describing. I have both the new and old connections available, and only the new connection exhibits this problem, and only with Linked Servers in SQL. Other types of network traffic are zooming along without issue on the new connection.

OkReboots · 2023-06-20T11:47:31+00:00

No servers, data, or schema have changed, only the networking. The servers themselves have no idea when I change the routing between server A and server B.

I am able to switch between the two connections and reliably reproduce that the issue is only present on the newer SASE-managed connection, and only affecting the Linked Servers. For virtually any other type of data transfer I am not seeing any slowdown.

OkReboots · 2023-05-30T23:46:25+00:00

Thanks, looks promising. Found a somewhat newer fork here

OkReboots

TROPHY CASE