Looking for 10.0.17763.168 support

[ZooShu]

Just trying the tool for the first time and I'm not sure what I'm doing. Already broke the server once and had to connect via KVM Console to get back on

Any help/steps would be great

https://i.imgur.com/hHgEY6u.png

Thanks in advance

Here's the dll file

https://transfer.sh/LaY0f/termsrv.zip

[stefan7n]

Just updated win10 home to 17763.168. Broke Rdp, :(

[DHaak93]

I am also having issues following Update to 10.0.17763.168
Please add support for this build

[bezik46]

Not good, too many times now it all go to pieces!

[hajubu]

Hello All . just have a look to #601 - hajubu - all you need is there. Good luck -

Well, it does work on the latest CU update to Win10., I am only allowed one connection at a time. When I log on other users get kicked off

I am using Win10 Pro 64 Bit.

[barakumis]

Good day. I installed 17763.168. And it all stopped working.
Please tell me in detail what needs to be done to make it work again?

[StarfighterJ]

17763.168 was installed now I also have stopped working LOL version 1809 was working so goo until now

[ZooShu]

hey haijubu, I followed the steps in #601 and I did the

net stop TermService net start TermService

and after that I did a reboot

but this is what I get

and I'm unable to connect via RDP to my server.

Right now I'm connected via TermViewer and this is what I tried

It's still the same and I'm unable to connect.

I have Windows 10 Enterprise installed with legit license

I tried starting it manually from services and this is what I get

Any help would be appreciated.

I only want multiple people to be able to connect using RDP at the same time, that is all

Thanks

[ZooShu]

Update:

Little modification and this is where I stand now

I had to restart Remote Desktop Services UserMode Port Redirector manually but still no luck

I also added 3389 to firewall rules. Both UDP and TCP for both incoming and outgoing just in case it might help.
Still no luck

Well, it does work on the latest CU update to Win10., I am only allowed one connection at a time. When I log on other users get kicked off

I am using Win10 Pro 64 Bit.

Once you install December 5, 2018—KB4469342 (OS Build 17763.168) CU update it limits the termserv.dll to one connection at a time, I did have a backup of termsrv.dll, replaced it, and now it is working again. Just a heads-up in case anyone else runs into the issue.

[barakumis]

I managed to do.
I took the file from this post #601 (comment)
replaced it at home.
And I added lines from the same post to my rdpwrap.ini file.

[hajubu]

Hello Team,
I did a full recheck for all version/builds 17763.1,.165,.167, .168
// last CU KB4469342 (v168.1.10 ) and SSU KB4470788 both from 2018-12-04 // msu::SSU must be installed before CU , only the 'older' KB4469342 (cab) should/(must) be overwritten. I also installed KB4471331(adobe flash) and KB 4469041 -preview CU upd NetFramew.3.5/4.72) which I believe not so important //
2 TestBeds) host x64pro and client x64 (Pro AND Home) __ !! ARE WORKING in both direction !!
i.e. local RDPcfg ,RDPchk and "life" from 17763.168 and to VM-Client-17763.165,.167,.168
AND a real x64pro-PC to a x64Home-PC
Look at #601 - hajubu posts (2018-11-21, -22 build .165, 18-12-07 and -08
-------2018-11-21------------
Something has changed from 17763.1 (incl .55, .107 and .134) to 17763.165 in the x64-data
[10.0.17763.165] // LocalOnlyOffset.x64=xxxxx
//xxxxx.(17763.1) =77941 --> xxxxx.(17763.165) =77AF1 ( tested and validated )
all other x64-ini-data for 1809rs517763.1 to .134 are the same as .165-data
hint: SingleUserOffset.x64=132F9 may be also ==1322C as in the original-ini from 2018-10-10
-------2018-11-22-------------

1. ;--------snip-----from here ... [10.0.17763.165] ...to... ;--------snip-------------
2. ;--------snip-----from here ... [10.0.17763.165SL-Init] ...to... ;--------snip-------------
3. read the snip ;------------------------use as batch / cmd ------------------------- or save it to a txt.file
4. termsrv.dll was meanwhile updated to .167(18-11-27) and .168(18-12-04),
   offsets seems to be the same as in .165. Therefore (if you have a need for it ) just change the ini header for the "new" build or ................
   Add for each build a section for [10.0.17763.nnn] and [10.0.17763.nnn-SLInit] with the data (in Add support for 10.0.17763.165 #601 -hajubu) using the snipping data [10.0.17763.165] and [10.0.17763.165-SLInit].
   ------2018-12-08----------
   Additional Remarks given another team member:
   For each build , you need the two ini-Section [10.0.17763.nnn] and [10.0.17763.nnn-SLInit] / nnn= (1 , 165, 167, 168 ) is given, which contains both (.x64 and .x86) offset-values.
   This ensures that all these builds will be recognized.
   I did a replication of my findings (snip-listing Sections [10.0.17763.165] and [10.0.17763.165-SLInit] above) for all three 177763.nnn-builds (165,167,168), adding these section by taking the original build from 2018-10-10 from the repository,containing already the both 177763.1 Sections( with 64 and x86)
   whereby the build-number were set according to the wanted build.
   (! There is a main difference from build 17763.1 to 17763.165).
   For better reading (and -may be- for the init of rdp-wrapper )
   I did put each section for itself behind 17763.1 and behind 17763.1-Slinit.
   Please be aware not stumbling over
   a) os-bit version
   b) not using "net stop TermService" and changing the "newly" edited ini-file.
   See my comment for a risk of overwriting this file using unmodified "install.bat/uninstall.bat" or the "update.bat" . batch/cmd in 3) and it might be a good idea to change in the [Main] section the Updated=yyyy-mm-dd to your "year-month-day" figures e.g. 2018-12-09
   c) after you have replaced the ini-file do restart the "PC" or at least use "start net TermService".
   Stopping and starting may have another trips/tripping , restart the system can be a better idea.
   Remark:
   Each build 17763.1 , .165 , 167 , 168 comes with an own "build" version of Termsrv.dll ( x64,x86).
   The rfxvmt.dll (x64 , x86 ) has always 17763.1, whereby the the added (older) rfxvmt.dll in syswow64 from the rdp-wrapper install also still works fine.
   Therefore in x64 you have several choices to circumvent the stumbling stones.
   Please let me know if this helped.
   Getting the Termsrv.dll and rfxvmt.dll from the dedicated install.wim (x64 / x86) or do a simple VM install of the OS-build of your choice ( my recommendation) and follow up the workflow,
   Exchanging a "dll" in a system you have to have special rights as you know already for sure.
   

[StarfighterJ]

I think I understand just copy and Paste 10.0.17763.1 data for .165 and a .168 correct?

Dumb Question why doesn't the RDPWrap-V1.62 update.bat do this for us?