rdp to azure hci os fails with event 40 disconnect code 12

%3CLINGO-SUB%20id%3D%22lingo-sub-2564475%22%20slang%3D%22en-US%22%3Erdp%20to%20azure%20hci%20os%20fails%20with%20event%2040%20disconnect%20code%2012%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2564475%22%20slang%3D%22en-US%22%3E%3CP%3Ethis%20problem%20appears%20on%20all%204%20nodes.%3CBR%20%2F%3E%3CBR%20%2F%3Eazure%20stack%20hci%20os%2010.0.17784%26nbsp%3B%3CBR%20%2F%3Ealso%20using%20windows%20admin%20center%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ein%20the%20beginning%20it%20was%20working.%20after%20the%20printnightmare%20series%20of%20updates%20I%20noticed%20the%20issue%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3CU%3Edescription%20of%20symptoms%3C%2FU%3E%3CBR%20%2F%3E%3CBR%20%2F%3E(normal%20operation)%3CBR%20%2F%3Ea)%20if%20the%20console%20user%20is%20logged%20in%20(after%20pressing%20ctrl%2Balt%2Bdel%20and%20signing%20in%20at%20the%20console).%20they%20see%20the%20sconfig%20screen.%26nbsp%3B%3CBR%20%2F%3Eb)%20if%20a%20remote%20user%20then%20logs%20in%20with%20the%20same%20credentials.%20everything%20is%20fine.%20they%20can%20log%20in%20as%20per%20normal%20etc.%3CBR%20%2F%3Ec)%20in%20windows%20admin%20center%2C%20under%20overview.%20you%20will%20see%20Logged%20in%20users%20%3D%201%3CBR%20%2F%3E%3CBR%20%2F%3E(abnormal%20operation)%3CBR%20%2F%3Ea)%20upon%20server%20reboot.%20or%20IF%20the%20logged%20in%20user%20does%20a%20log%20off%20(sconfig%20option%2012)%20(whether%20at%20console%20or%20remotely)%3CBR%20%2F%3Eif%20a%20remote%20user%20wants%20to%20rdp%20in%2C%20it%20immediately%20fails.%3CBR%20%2F%3Ethe%20log%20will%20see%20%22session%20x%20has%20been%20disconnected%2C%20reason%20code%2012%22%2C%20event%20id%2040%20under%20terminalservices-localsessionmanager%3CBR%20%2F%3E%3CBR%20%2F%3Eb)%20windows%20admin%20center%20at%20this%20point%20will%20display%20a%20logged%20in%20users%20count%20of%20-1%20(not%200)%20.%3CBR%20%2F%3E%3CBR%20%2F%3Ec)%20once%20the%20console%20user%20logs%20in%2C%20everything%20works.%3CBR%20%2F%3E%3CBR%20%2F%3E---%3CBR%20%2F%3Eits%20a%20minor%20but%20annoying%20bug%20though.%3CBR%20%2F%3E%3CBR%20%2F%3Eso%20there%20are%20viable%20workarounds.%3CBR%20%2F%3Eyou%20can%20still%20user%20server%20manager%20at%20the%20management%20pc%20to%20run%20computer%20management%2C%20powershell%20etc%20against%20the%20headless%20azure%20hci.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20initially%20thought%20it%20was%20GPO%20hardening%20settings%20that%20was%20initially%20applied%20(azure%20hci%20os%20says%20you%20shouldn't%20have%20any%20hardening).%20so%20after%20the%20problem%20showed%20up%2C%20I%20excluded%20it%20from%20any%20policies%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2564475%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3ENetworking%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Occasional Contributor

this problem appears on all 4 nodes.

azure stack hci os 10.0.17784 
also using windows admin center

 

in the beginning it was working. after the printnightmare series of updates I noticed the issue 

description of symptoms

(normal operation)
a) if the console user is logged in (after pressing ctrl+alt+del and signing in at the console). they see the sconfig screen. 
b) if a remote user then logs in with the same credentials. everything is fine. they can log in as per normal etc.
c) in windows admin center, under overview. you will see Logged in users = 1

(abnormal operation)
a) upon server reboot. or IF the logged in user does a log off (sconfig option 12) (whether at console or remotely)
if a remote user wants to rdp in, it immediately fails.
the log will see "session x has been disconnected, reason code 12", event id 40 under terminalservices-localsessionmanager

b) windows admin center at this point will display a logged in users count of -1 (not 0) .

c) once the console user logs in, everything works.

---
its a minor but annoying bug though.

so there are viable workarounds.
you can still user server manager at the management pc to run computer management, powershell etc against the headless azure hci.

I initially thought it was GPO hardening settings that was initially applied (azure hci os says you shouldn't have any hardening). so after the problem showed up, I excluded it from any policies 



1 Reply
I have some idea of a "workable workaround" by configuring autoadminlogon though.