Changing password in RDS-in-RDS session

It was already a common knowledge for me that for starting password changing dialog in a remote session CTRL+ALT+End shortcut should be used instead of CTRL+ALT+DEL. Simply because the latter always opens the dialog on the outer computer.

There is a Registry change that forces almost all shortcuts to be handled by a remote session. In the following key set the value for "TransparentKeyPassthrough" to "Remote". Unfortunately it does not work for CTRL+ALT+DEL.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Keyboard

A solution is to start the on-screen keyboard (OSK.EXE), press CTRL+ALT on the physical keyboard, and then press DEL on the on-screen keyboard. This places the shortcut exactly where it should be placed -- in a session that hosts the instance of the on-screen keyboard.

This trick works even if you are in a remote session launched from a remote session.

After sharing this information with colleagues, I was stunned to find -- LOL -- "Windows Security" item in the Start Menu. As they say: these things happen.

Cannot add a SimpleContent column to a table containing element columns or nested relation

This is a classic case of an error message that is not exactly a misleading one, but one that must be interpreted properly.

This is the story. In a WCF application, I added a dataset based on T-SQL query. Everything worked as expected. In my tests, I was able to fill a dataset, and send it back to WCF client. The dataset was a public member of a class instance.

My next step was moving the actual query to a stored procedure. The purpose was to keep consistent design across the WCF application. All dataset in the app were designed to call respective stored procedures, rather than execute direct SQL SELECT statements.

This is were my WCF client started to throw an exception: Cannot add a SimpleContent column to a table containing element columns or nested relation.

I admit giving only a little effort understanding the error message. And yes, I googled the text of the error message, a lazy approach. Then I tried to change the stored procedure first to an inline function, and then to a multi-statement function. As you understand, the outcome was exactly the same.

The actual System.Data.SqlClient.SqlException error, and I had to caught it on WCF server side, was caused by missing SELECT permission on SQL Server function I created. So there was no valid dataset returned with WCF server's responses, which subsequently was causing deserialization fail on WCF client side. Simple!